IBM Tivoli NetView for z/OS Installation: Configuring Additional

Tivoli IBM Tivoli NetView for z/OS
®
Version 5 Release 4
Installation: Configuring Additional Components
SC31-8874-07
Tivoli IBM Tivoli NetView for z/OS
®
Version 5 Release 4
Installation: Configuring Additional Components
SC31-8874-07
Note
Before using this information and the product it supports, read the information in “Notices” on page 243.
This edition applies to version 5, release 4 of IBM Tivoli NetView for z/OS (product number 5697-ENV) and to all
subsequent versions, releases, and modifications until otherwise indicated in new editions.
This edition replaces SC31-8874-06.
© Copyright International Business Machines Corporation 2001, 2009.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
About this publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Intended audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
IBM Tivoli NetView for z/OS library . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Accessing terminology online . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Using NetView for z/OS online help . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Using LookAt to look up message explanations . . . . . . . . . . . . . . . . . . . . . . xvi
Accessing publications online . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Ordering publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Tivoli technical training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Downloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Support for problem solving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Conventions used in this publication . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Typeface conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Operating system-dependent variables and paths . . . . . . . . . . . . . . . . . . . . . xix
Syntax diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Command Facility . . . . . . . . . . . . . .
Hardware Monitor . . . . . . . . . . . . . .
Session Monitor . . . . . . . . . . . . . . .
Terminal Access Facility . . . . . . . . . . . .
SNA Topology Manager . . . . . . . . . . . .
4700 Support Facility . . . . . . . . . . . . .
Automated Operations Network . . . . . . . . . .
MultiSystem Manager . . . . . . . . . . . . .
Browse Facility . . . . . . . . . . . . . . .
Automation Table. . . . . . . . . . . . . . .
Status Monitor. . . . . . . . . . . . . . . .
Resource Object Data Manager . . . . . . . . . .
Graphic Monitor Facility Host Subsystem. . . . . . .
IBM Tivoli NetView for z/OS Enterprise Management Agent
Subsystem Interface . . . . . . . . . . . . . .
Correlation Engine . . . . . . . . . . . . . .
Common Base Event Manager . . . . . . . . . .
Event/Automation Service. . . . . . . . . . . .
UNIX System Services . . . . . . . . . . . . .
Help Facility . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
2
2
2
3
3
3
3
4
4
4
4
5
5
6
6
6
7
7
Chapter 2. Defining NetView Components . . . . . . . . . . . . . . . . . . . . . 9
Defining the Command Facility . . . . . . . . . . . .
Including Additional Task Statements . . . . . . . . .
Defining Command Facility Panel Format . . . . . . .
Assembling and Link-Editing the NetView Constants Module
Boundary Function Trace Initialization Timeout . . . .
Connectivity Test Timeout . . . . . . . . . . .
Gateway TRACE Initialization Timeout . . . . . . .
Gateway Boundary Function Trace Request Timeout . . .
LINEMAP Command Timeout . . . . . . . . . .
NCP Boundary Function Trace Data Request Timeout . .
Nonpersistent Sessions Timeout Value . . . . . . .
© Copyright IBM Corp. 2001, 2009
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 9
. 9
. 10
. 10
. 10
. 10
. 10
. 11
. 11
. 11
. 11
iii
Query PSID Request Timeout . . . . . . . . . . . . . . .
Route Test Initialization Timeout . . . . . . . . . . . . . .
RTM Collection Request Timeout . . . . . . . . . . . . . .
RTM Initialization Request Timeout . . . . . . . . . . . . .
Service Point Control Interface Commands Timeout . . . . . . . .
TRACE NCP Command Timeout . . . . . . . . . . . . . .
VR Status Request Timeout . . . . . . . . . . . . . . . .
Hardware Monitor Remote Data Retrieval Timeout . . . . . . . .
Hardware Monitor Solicited Commands Timeout . . . . . . . . .
HLL Default Stack Size . . . . . . . . . . . . . . . . .
HLL Default HEAP Area . . . . . . . . . . . . . . . . .
Task Public Message Queue Thresholds . . . . . . . . . . . .
Maximum Number of APPCCMD Retries . . . . . . . . . . .
Entry for LU 6.2 Transport Support . . . . . . . . . . . . .
Timeout Value for CSCF . . . . . . . . . . . . . . . . .
CSCF Application Idle Timeout . . . . . . . . . . . . . . .
Storage Management Performance . . . . . . . . . . . . . .
Automation Table Loading . . . . . . . . . . . . . . . .
RTM Initialization Retry and Interval . . . . . . . . . . . . .
Expected Number of Task Global Variables . . . . . . . . . . .
Expected Number of Common Global Variables . . . . . . . . .
Sense Code Filtering . . . . . . . . . . . . . . . . . .
Defining Generic Automation Receiver Support . . . . . . . . . .
Reviewing System Definitions . . . . . . . . . . . . . . . .
Defining Buffer Pools . . . . . . . . . . . . . . . . . . .
Buffer Pool Sizes . . . . . . . . . . . . . . . . . . .
Minimum Buffer Allocations. . . . . . . . . . . . . . . .
Additional Buffer Allocations . . . . . . . . . . . . . . .
Changes to CNMSJM01 . . . . . . . . . . . . . . . . .
Defining VSAM Performance Options . . . . . . . . . . . . .
Defining the MEMSTORE Function . . . . . . . . . . . . . .
Defining the Status Monitor . . . . . . . . . . . . . . . . . .
Processing Command Lists from the Status Monitor . . . . . . . . .
Specifying the Designated Interface with VTAM . . . . . . . . . .
Specifying the Automatic Reactivation of Failing Nodes . . . . . . .
Modifying the Message Indicator Settings . . . . . . . . . . . .
Providing Status Information for Automated Recovery of Failing Devices .
Specifying the Initial Status for Resources Not Known to VTAM. . . . .
Defining SNA Resources to the Status Monitor . . . . . . . . . .
Defining the Nodes. . . . . . . . . . . . . . . . . . .
Defining the Network and Creating CNMCONxx . . . . . . . .
Defining Resources by Names You Choose . . . . . . . . . . .
Defining a Channel to the Status Monitor . . . . . . . . . . .
Defining a Host Physical Unit Name for Status Forwarding . . . . .
Running the Status Monitor Preprocessor . . . . . . . . . . .
Determining the Program Region Size for the Status Monitor Preprocessor
Starting the Status Monitor . . . . . . . . . . . . . . . . .
Testing the Status Monitor . . . . . . . . . . . . . . . . .
Stopping the Status Monitor . . . . . . . . . . . . . . . . .
Defining the Hardware Monitor . . . . . . . . . . . . . . . .
Defining Passwords . . . . . . . . . . . . . . . . . . .
Defining Additional Generic Alert Code Points . . . . . . . . . .
Changing the Colors of the Sample Network . . . . . . . . . . .
Starting the Hardware Monitor . . . . . . . . . . . . . . . .
Stopping the Hardware Monitor . . . . . . . . . . . . . . .
Defining the 4700 Support Facility . . . . . . . . . . . . . . . .
Defining Passwords . . . . . . . . . . . . . . . . . . .
Starting the 4700 Support Facility . . . . . . . . . . . . . . .
Stopping the 4700 Support Facility . . . . . . . . . . . . . .
Defining the Session Monitor . . . . . . . . . . . . . . . . .
Defining Passwords . . . . . . . . . . . . . . . . . . .
iv
Installation: Configuring Additional Components
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
12
12
12
12
12
13
13
13
13
13
14
14
14
14
14
15
15
15
15
16
16
16
17
17
18
18
19
20
21
21
21
22
22
23
23
24
24
25
26
26
29
29
29
31
31
31
33
33
34
34
35
35
35
35
35
36
36
36
37
Defining Sense Code Filtering . . . . . . . . . . . . . . .
Deciding Which Sense Codes to Filter . . . . . . . . . . .
Adding a Sense Code for Filtering . . . . . . . . . . . . .
Stopping Sense Code Filtering . . . . . . . . . . . . . .
Defining Session Awareness (SAW) Data. . . . . . . . . . . .
Coding KCLASS and MAPSESS Statements in the NetView Program .
Discarding SAW Data . . . . . . . . . . . . . . . . .
Starting the Session Monitor . . . . . . . . . . . . . . . .
Stopping the Session Monitor . . . . . . . . . . . . . . .
Defining AON . . . . . . . . . . . . . . . . . . . . .
Setting Up Base AON . . . . . . . . . . . . . . . . . .
Updating CNMSTYLE . . . . . . . . . . . . . . . . .
Allocating VSAM Clusters . . . . . . . . . . . . . . .
Defining Passwords . . . . . . . . . . . . . . . . .
Adding Gateway and Automation Operator Definitions and Passwords
Changing the Domain ID . . . . . . . . . . . . . . . .
Updating the NetView Startup Procedure . . . . . . . . . .
Updating the Control File Policy Definitions . . . . . . . . .
Restricting Access to AON Commands and Menu Selections . . . .
Adding REXX Environment Blocks . . . . . . . . . . . .
Setting Up AON/TCP Support . . . . . . . . . . . . . . .
Defining AON/TCP Functions . . . . . . . . . . . . . .
Enabling IP390 Automation . . . . . . . . . . . . . . .
Disabling Tivoli NetView for AIX Support for TCP/IP . . . . . .
Defining Command Servers to AON/TCP . . . . . . . . . .
Configuring NetView SNMP Support. . . . . . . . . . . .
Configuring AON/TCP SNMP Support . . . . . . . . . . .
Defining Local TCP/IP Stacks . . . . . . . . . . . . . .
Setting Up Cross-Domain Communication . . . . . . . . . .
Defining TCP/IP Autotasks . . . . . . . . . . . . . . .
Setting Up for Proactive Monitoring of IP Resources. . . . . . .
Resolving Community Names (Optional) . . . . . . . . . .
Managing TCP/IP Connections . . . . . . . . . . . . . .
Defining TCP/IP Connection Monitoring Policy . . . . . . . .
Enabling Intrusion Detection Services. . . . . . . . . . . .
Customizing TCP/IP Tracing . . . . . . . . . . . . . .
Setting Up AON/SNA Support . . . . . . . . . . . . . . .
Updating the Status Monitor . . . . . . . . . . . . . .
Defining the Subsystem Interface Address Space . . . . . . . .
Setting Up AON/SNA Subarea Support . . . . . . . . . . .
Enabling Advanced Peer-to-Peer Networking Monitoring Support . .
Implementing X.25 Monitoring . . . . . . . . . . . . . .
Completing AON Tailoring . . . . . . . . . . . . . . . .
Testing AON Automation. . . . . . . . . . . . . . . . .
Testing the Enhanced Automation . . . . . . . . . . . . .
Verifying AON Tasks . . . . . . . . . . . . . . . . .
Verifying AON Panels . . . . . . . . . . . . . . . . .
Testing AON Commands . . . . . . . . . . . . . . . .
Testing AON/SNA . . . . . . . . . . . . . . . . . . .
Testing AON/SNA VTAM Subarea Automation . . . . . . . .
Testing AON/SNA Advanced Peer-to-Peer Networking Monitoring .
Testing AON/SNA X.25 Monitoring . . . . . . . . . . . .
Setting Up Focal-point Services . . . . . . . . . . . . . . .
Automation Notification Forwarding Design . . . . . . . . .
Gateways . . . . . . . . . . . . . . . . . . . . .
Passwords . . . . . . . . . . . . . . . . . . . . .
Connection . . . . . . . . . . . . . . . . . . . .
Command and Response Routing . . . . . . . . . . . . .
NetView Definitions . . . . . . . . . . . . . . . . .
Example of Focal Point Implementation . . . . . . . . . . .
Implementing Notification Forwarding . . . . . . . . . . .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
(SAF
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
only)
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Contents
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
38
39
40
41
41
42
43
43
43
44
44
45
46
46
47
47
48
51
52
52
55
56
56
56
58
59
59
60
62
62
64
64
65
65
66
66
67
67
68
68
69
69
70
70
70
70
71
72
72
75
77
81
81
83
84
85
85
86
86
91
v
Installing RACF Gateway Automation Operator Password Option .
GETPW - Gateway Password Maintenance . . . . . . . . .
Defining RMTCMD Gateway Sessions . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 93
. 94
. 94
Chapter 3. Configuring the Operator Environment . . . . . . . . . . . . . . . . . 97
Defining NetView Operators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Specifying the Degree of Security Verification . . . . . . . . . . . . . . . . . . . . . . . . 97
Defining Operator Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Assigning Operators to Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Suppressing Commands After Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Defining PA and PF Keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Defining Hardcopy Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Setting Initial Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Defining Domains Where This NetView Program Can Establish Cross-Domain Communication . . . . . . . 100
Chapter 4. Installing and Configuring the Web Application . . . . . . . . . . . . . 103
Understanding Web Application Servers and Web Applications.
Web Application Server . . . . . . . . . . . . .
Web and Enterprise Applications . . . . . . . . . .
Installing the NetView Web Application . . . . . . . .
Defining the NetView Web Server Interface Task (DSIWBTSK) .
Setting Up Access for the Web Application . . . . . . .
Changing the First Task Displayed . . . . . . . . . .
Controlling Access to Tasks. . . . . . . . . . . . .
Configuring User Preferences . . . . . . . . . . . .
Configuring the Web Application To Display Performance Data
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
103
103
103
104
104
105
106
106
107
107
Chapter 5. Extending the Command Environment . . . . . . . . . . . . . . . . . 109
Using Language Processor (REXX) Environments in the NetView Environment . . . . . . . . . . . . 109
Estimating REXX Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Storage Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Using High-Level Languages with the NetView Program . . . . . . . . . . . . . . . . . . . . 113
Defining Commands and Command Lists . . . . . . . . . . . . . . . . . . . . . . . . . 114
Adding Command Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Specifying a Command Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Loading a Command Module Only When That Command Is Run . . . . . . . . . . . . . . . . 115
Creating a Synonym for a Command or Command List . . . . . . . . . . . . . . . . . . . 116
Suppressing Command Echoes . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Creating Command Keyword Synonyms . . . . . . . . . . . . . . . . . . . . . . . . 117
Issuing System and Subsystem Commands from the NetView Console . . . . . . . . . . . . . . . 118
Chapter 6. Configuring Optional NetView Services . . . . . . . . . . . . . . . . 119
|
|
|
|
|
Defining Management Services Transport . . . . . . . .
Defining High Performance Transport . . . . . . . . .
Defining the Save/Restore Function . . . . . . . . . .
Defining DB2 Subsystem Access . . . . . . . . . . .
Starting the TSO Command Server . . . . . . . . . .
Starting the UNIX Command Server. . . . . . . . . .
Enabling the NetView for z/OS Discovery Library Adapter . .
Configuring the Discovery Library Adapter . . . . . .
Confirming the NetView for z/OS and Tivoli NetView Setup
Accessing the IBM Tivoli CCMDB File Server . . . . .
Using a TSO Command Server . . . . . . . . . .
Setting the IBM Tivoli CCMDB File Server Password . . .
Running the Discovery Library Adapter . . . . . . .
Configuring NetView Web Services Gateway . . . . . . .
Configuring the NetView program . . . . . . . . .
Configuring the CNMSTYLE Member . . . . . . .
Updating the NetView Startup Procedure . . . . . .
Configuring Security . . . . . . . . . . . . .
vi
Installation: Configuring Additional Components
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
119
120
120
121
122
124
124
124
125
126
126
127
127
128
128
128
129
130
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Preparing the MVS System . . . .
Preparing the Web Resources Files .
Verifying NetView Web Services . .
.
.
.
.
.
.
.
.
.
Chapter 7. Enabling IP Management
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 130
. 130
. 131
. . . . . . . . . . . . . . . . . . . . . . 133
IP Enablement Overview . . . . . . . . . . . . . . . .
Setting Required Statements for IP Management. . . . . . . . .
Setting Policy Statements . . . . . . . . . . . . . . . .
Enabling TCP/IP Services . . . . . . . . . . . . . . . .
Enabling TCP/IP Connection and Packet Trace Data Collection. . . .
Enabling DVIPA Management . . . . . . . . . . . . . . .
DVIPA Data Collection . . . . . . . . . . . . . . . .
DVIPA Events . . . . . . . . . . . . . . . . . . .
DVIPA Traps . . . . . . . . . . . . . . . . . .
DVIPA TCPIP Profile Updates . . . . . . . . . . . . .
Sysplex Monitoring Messages . . . . . . . . . . . . .
DVIPA Event Delay Timers . . . . . . . . . . . . . .
Distributed DVIPA Statistics . . . . . . . . . . . . . .
User Interface Configuration for DVIPA Management . . . . . .
Configuring the NetView for z/OS Enterprise Management Agent
Configuring the NetView Web Application . . . . . . . .
Enabling the Discovery Manager . . . . . . . . . . . . . .
Discovery Manager Data Collection . . . . . . . . . . . .
Multiple NetView Programs on a Single z/OS Image . . . . . .
User Interface Configuration for Discovery Manager . . . . . .
Using the NetView Management Console . . . . . . . . .
Using the Tivoli NetView for z/OS Enterprise Management Agent
Defining Critical IP Port Monitoring . . . . . . . . . . . . .
Enabling IP Functions with the IPMGT Tower . . . . . . . . .
Setting Up TCP/IP Support for the AON IP Functions . . . . . .
Defining AON IP Functions . . . . . . . . . . . . . .
Defining UNIX Command Servers . . . . . . . . . . . .
Configuring SNMP Support for AON IP Functions . . . . . . .
Defining Local TCP/IP Stacks . . . . . . . . . . . . . .
Setting Up Cross-Domain Communication. . . . . . . . . .
Defining TCP/IP Autotasks . . . . . . . . . . . . . .
Setting Up for Proactive Monitoring of IP Resources . . . . . .
Pinging a Resource . . . . . . . . . . . . . . . .
MIB Polling . . . . . . . . . . . . . . . . . . .
MIB Thresholding . . . . . . . . . . . . . . . . .
Resolving Community Names (Optional) . . . . . . . . . .
Managing TCP/IP Connections with AON IP Functions . . . . .
Defining TCP/IP Connection Monitoring Policy . . . . . . . .
Enabling Intrusion Detection Services . . . . . . . . . . .
Customizing TCP/IP Tracing . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
133
134
135
135
136
139
139
139
140
141
141
141
142
142
143
143
143
144
145
145
145
145
146
146
146
148
149
150
150
151
151
152
152
152
153
153
153
154
154
155
Chapter 8. Configuring NetView Sysplex Management . . . . . . . . . . . . . . . 157
Configuring XCF Services . . . . . . . . . . . . . . . . .
Defining the NetView Role in a Sysplex . . . . . . . . . . .
Defining an Enterprise RODM. . . . . . . . . . . . . . .
Coordinating with TCP/IP Configuration for DVIPA Support . . . .
Considerations for Master Switches . . . . . . . . . . . . .
Multiple NetView Groups . . . . . . . . . . . . . . . .
Configuring DVIPA Management for Display at a Master NetView Program
Configuring Discovery Manager for Display at a Master NetView Program.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
157
157
159
159
160
161
162
163
Chapter 9. Defining and Maintaining Data Logs and Databases . . . . . . . . . . . 165
Maintaining the Session Monitor Database
Defining the JES Job Log . . . . . .
Defining the Network Log . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Contents
. 165
. 166
. 166
vii
Defining Passwords for the Network Log . . . . . . .
Switching Recording Between Primary and Secondary Logs .
Printing the Network Log . . . . . . . . . . . . .
Defining Sequential Access Method Logging Support . . . .
Allocating and Defining a Sequential Log Data Set . . . .
Block Size (BLKSIZE). . . . . . . . . . . . . .
Data Set Disposition (DISP) . . . . . . . . . . .
Defining the Sequential Logging Function . . . . . . .
CNMPROC (CNMSJ009) . . . . . . . . . . .
Installing the Interactive Problem Control System . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
166
166
167
170
170
171
171
171
173
173
Chapter 10. Centralizing Operations. . . . . . . . . . . . . . . . . . . . . . . 175
|
Forwarding Data to Architectural Focal Points . . . . . . . . .
Forwarding Operations Management Data through LU 6.2 . . . .
DEFFOCPT Statement . . . . . . . . . . . . . . .
DEFENTPT Statement . . . . . . . . . . . . . . .
Forwarding Alerts through LU 6.2 . . . . . . . . . . . .
Setting Up an Alert Focal Point . . . . . . . . . . . .
Setting Up an Alert Entry Point . . . . . . . . . . . .
Setting up an Intermediate Node Alert Focal Point . . . . . .
Additional Considerations for Forwarding Alerts through LU 6.2 .
Forwarding Alerts Using TCP/IP. . . . . . . . . . . . .
Forwarding User-Defined Data through LU 6.2 . . . . . . . .
Setting Up a User-Defined Focal Point . . . . . . . . . .
Setting Up a User-Defined Entry Point . . . . . . . . . .
Defining the Entry Points in the Sphere of Control of a Focal Point .
Forwarding Data to NetView Focal Points . . . . . . . . . . .
Forwarding Alerts through LUC . . . . . . . . . . . . .
Setting Up an LUC Alert Focal Point . . . . . . . . . .
Setting Up a Distributed Host . . . . . . . . . . . . .
Additional Considerations for Forwarding Alerts through LUC. .
Establishing Nonpersistent Sessions . . . . . . . . . . . .
Examples . . . . . . . . . . . . . . . . . . . .
Defining Advanced Peer-to-Peer Networking Session Configurations .
Defining the Terminal Access Facility . . . . . . . . . . .
Defining Additional Source LUs . . . . . . . . . . . .
Accessing the Customer Information Control System Using TAF .
Accessing the Information Management System Using TAF . . .
Accessing TSO Using TAF . . . . . . . . . . . . . .
Accessing CLSDST(PASS) Applications Using TAF . . . . . .
Using TAF with Default LU Names . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
175
175
176
176
177
177
177
178
178
179
179
179
179
180
181
182
182
183
184
184
185
185
186
187
188
189
189
189
189
Chapter 11. Defining Automation . . . . . . . . . . . . . . . . . . . . . . . . 191
|
|
|
|
|
|
|
Updating the Automation Table . . . . . . . . . . . . . .
Defining Frame Relay and LMI Support . . . . . . . . . .
Handling Undeleted MVS Messages . . . . . . . . . . . .
Defining VSAM Database Automation . . . . . . . . . . .
Forwarding Alerts and Messages to the IBM Tivoli Enterprise Console
Revising MVS Messages . . . . . . . . . . . . . . . . .
Enabling MVS Command Revision . . . . . . . . . . . . .
Configuring the NetView Program . . . . . . . . . . . .
Preparing the MVS System . . . . . . . . . . . . . . .
Activating Command Revision . . . . . . . . . . . . .
Enabling Workload Management to Manage the NetView Program . .
Preparing WLM for the NetView Environment . . . . . . . .
Enabling WLM Support . . . . . . . . . . . . . . . .
Verifying WLM Support . . . . . . . . . . . . . . . .
Enabling SMF Record Type 30 Automation . . . . . . . . . .
Configuring the NetView program . . . . . . . . . . . .
Configuring SMF30 statements in CNMSTYLE . . . . . . .
viii
Installation: Configuring Additional Components
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
191
191
192
192
192
193
193
193
193
194
194
194
196
196
197
197
197
|
|
|
|
|
|
|
|
Defining the AUTOSMF3 autotask . . . . . . .
Defining the DSISMF3F command . . . . . . .
Defining automated processing for message BNH874I .
Updating the automation table . . . . . . . .
Preparing the MVS System . . . . . . . . . . .
Assemble and Link-Edit the CNMSMF3E Exit . . .
Update SYS1.PARMLIB Library . . . . . . . .
Verifying the SMF 30 processing . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
197
197
198
198
198
198
198
198
Chapter 12. Setting Up UNIX System Services for the NetView Program . . . . . . . 201
|
|
TCP/IP Considerations . . . . . . . . . . . . . . . .
Modifying UNIX System Services System Parameters . . . . . .
Creating Directories and Copying MIB Source Files. . . . . . .
Updating UNIX System Services Environment Variables . . . . .
Specifying NetView z/OS UNIX Environment Variables . . . .
Managing NetView z/OS UNIX Functions from z/OS UNIX . .
Enabling the UNIX Command Server . . . . . . . . . . .
Defining the UNIX Command Server . . . . . . . . . .
Starting the UNIX Command Server. . . . . . . . . . .
Starting from UNIX for z/OS . . . . . . . . . . . .
Verifying that the UNIX Command Server is Active . . . .
Enabling the Event/Automation Service . . . . . . . . . .
Preparing the z/OS Host Components . . . . . . . . . .
Preparing to Start as a Job . . . . . . . . . . . . .
Preparing to Start in a UNIX System Service Command Shell .
Getting Ready to Start the Event/Automation Service . . . . .
Getting Ready to Start the Alert Adapter Service . . . . .
Getting Ready to Start the Message Adapter Service . . . .
Getting Ready to Start the Confirmed Alert Adapter Service. .
Getting Ready to Start the Confirmed Message Adapter Service
Getting Ready to Start the Event Receiver Service . . . . .
Getting Ready to Start the Trap-to-Alert Service . . . . . .
Getting Ready to Start the Alert-to-Trap Service . . . . . .
Starting the Event/Automation Service . . . . . . . . . .
Starting the Event/Automation Service Using Job IHSAEVNT .
Starting the Event/Automation Service Using the UNIX System
Enabling Event Correlation and the Common Event Infrastructure .
Installing the Event Correlation Engine . . . . . . . . . .
Installing the Common Event Infrastructure Server and Client . .
Creating the Event Correlation Engine Rules . . . . . . . .
Updating the XML Correlation Rules . . . . . . . . . .
Starting the Correlation Engine . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
Services Command Shell .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
201
203
204
205
207
207
208
208
209
210
210
210
211
211
212
213
213
213
214
214
215
215
216
216
216
216
217
217
217
218
218
218
Chapter 13. Enabling the NetView Program with Other Products . . . . . . . . . . 219
Tivoli Management Regions . . .
System Automation for z/OS . . .
System Operations . . . . .
CICS Automation . . . . . .
IMS Automation . . . . . .
DB2 Automation . . . . . .
TWS Automation . . . . . .
Processor Operations . . . . .
I/O Operations. . . . . . .
Tivoli NetView Program . . . . .
Tivoli Business Systems Manager . .
Tivoli OMEGAMON XE Products .
IBM Tivoli Change and Configuration
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
Management Database
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
219
219
220
220
220
221
221
221
221
221
222
222
222
Chapter 14. Installing the Globalization Feature. . . . . . . . . . . . . . . . . . 225
|
Installing a Globalization Feature .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Contents
. 225
ix
|
|
Creating Translated Messages . . . . . . . . . . . . . . . . . .
Formatting of Globalization Feature Message Skeletons . . . . . . . .
Counting English Message Inserts for Globalization Feature Message Skeletons
SNMP Limitations . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
226
227
229
230
Appendix A. Running Multiple NetView Programs in the Same LPAR . . . . . . . . 231
Configuring the Two NetView Programs . . . . .
NetView Task Restrictions . . . . . . . . . .
Using the Subsystem Router in a Sysplex Environment
Assigning a Unique CNMCSSIR Task Name . . . .
Starting the NetView Program Before Starting JES . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
231
235
236
236
236
Appendix B. Data Collection and Display for the NetView User Interfaces . . . . . . 239
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Programming Interfaces .
Trademarks . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 244
. 245
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
x
Installation: Configuring Additional Components
Figures
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
NetView Program Host Components . . . . 1
Status Monitor Domain Status Summary Panel 32
Status Monitor Network Log . . . . . . . 32
Sense Code Report . . . . . . . . . . 38
Sample (as Supplied with the NetView
Program) . . . . . . . . . . . . . 39
Sample (with Sense Code 087D0001 Added)
40
EZLTLOG statements . . . . . . . . . 50
Notification Forwarding Hierarchy . . . . . 82
Gateway Names in a Distributed Network
83
Adjacent NetView Programs . . . . . . . 86
© Copyright IBM Corp. 2001, 2009
11.
12.
13.
14.
15.
16.
17.
Notification Forwarding Hierarchy . . . .
Notification Forwarding Example . . . .
Gateway Names in a Distributed Network
Example of a Sequential Log Task. . . .
Inserting WLM Rules . . . . . . . .
Messages for Starting the Event/Automation
Service . . . . . . . . . . . . .
Messages for Starting the Event/Automation
Service from a UNIX System Services
Command Shell. . . . . . . . . .
. 87
. 92
95
. 173
. 196
. 216
. 217
xi
xii
Installation: Configuring Additional Components
About this publication
The IBM® Tivoli® NetView® for z/OS® product provides advanced capabilities that
you can use to maintain the highest degree of availability of your complex,
multi-platform, multi-vendor networks and systems from a single point of control.
This publication, IBM Tivoli NetView for z/OS Installation: Configuring Additional
Components, provides information for system programmers to use in configuring
additional functions beyond the base functions of the NetView program for their
enterprise.
Intended audience
This publication is for system programmers, network planners, and system
designers who install additional components for the NetView program.
Publications
This section lists publications in the IBM Tivoli NetView for z/OS library and
related documents. It also describes how to access Tivoli publications online and
how to order Tivoli publications.
IBM Tivoli NetView for z/OS library
The following documents are available in the IBM Tivoli NetView for z/OS library:
v Administration Reference, SC31-8854, describes the NetView program definition
statements required for system administration.
v Application Programmer’s Guide, SC31-8855, describes the NetView
program-to-program interface (PPI) and how to use the NetView application
programming interfaces (APIs).
v Automation Guide, SC31-8853, describes how to use automated operations to
improve system and network efficiency and operator productivity.
v Command Reference Volume 1 (A-N), SC31-8857, and Command Reference Volume 2
(O-Z), SC31-8858, describe the NetView commands, which can be used for
network and system operation and in command lists and command procedures.
v Customization Guide, SC31-8859, describes how to customize the NetView product
and points to sources of related information.
v Data Model Reference, SC31-8864, provides information about the Graphic
Monitor Facility host subsystem (GMFHS), SNA topology manager, and
MultiSystem Manager data models.
v Installation: Configuring Additional Components, SC31-8874, describes how to
configure NetView functions beyond the base functions.
v Installation: Configuring Graphical Components, SC31-8875, describes how to install
and configure the NetView graphics components.
v Installation: Configuring the Tivoli NetView for z/OS Enterprise Management Agent,
SC31-6969, describes how to install and configure the NetView for z/OS
Enterprise Management Agent.
v Installation: Getting Started, SC31-8872, describes how to install and configure the
base NetView functions.
© Copyright IBM Corp. 2001, 2009
xiii
v Installation: Migration Guide, SC31-8873, describes the new functions provided by
the current release of the NetView product and the migration of the base
functions from a previous release.
v IP Management, SC27-2506, describes how to use the NetView product to manage
IP networks.
v Messages and Codes Volume 1 (AAU-DSI), SC31-6965, and Messages and Codes
Volume 2 (DUI-IHS), SC31-6966, describe the messages for the NetView product,
the NetView abend codes, the sense codes that are included in NetView
messages, and generic alert code points.
v Programming: Assembler, SC31-8860, describes how to write exit routines,
command processors, and subtasks for the NetView product using assembler
language.
v Programming: Pipes, SC31-8863, describes how to use the NetView pipelines to
customize a NetView installation.
v Programming: PL/I and C, SC31-8861, describes how to write command processors
and installation exit routines for the NetView product using PL/I or C.
v Programming: REXX and the NetView Command List Language, SC31-8862, describes
how to write command lists for the NetView product using the Restructured
Extended Executor language (REXX) or the NetView command list language.
v Resource Object Data Manager and GMFHS Programmer’s Guide, SC31-8865,
describes the NetView Resource Object Data Manager (RODM), including how
to define your non-SNA network to RODM and use RODM for network
automation and for application programming.
v Security Reference, SC31-8870, describes how to implement authorization checking
for the NetView environment.
v SNA Topology Manager Implementation Guide, SC31-8868, describes planning for
and implementing the NetView SNA topology manager, which can be used to
manage subarea, Advanced Peer-to-Peer Networking, and TN3270 resources.
v Troubleshooting Guide, GC27-2507, provides information about documenting,
diagnosing, and solving problems that might occur in using the NetView
product.
v Tuning Guide, SC31-8869, provides tuning information to help achieve certain
performance goals for the NetView product and the network environment.
v User’s Guide: Automated Operations Network, GC31-8851, describes how to use the
NetView Automated Operations Network (AON) component, which provides
event-driven network automation, to improve system and network efficiency. It
also describes how to tailor and extend the automated operations capabilities of
the AON component.
v User’s Guide: NetView, GC31-8849, describes how to use the NetView product to
manage complex, multivendor networks and systems from a single point.
v User’s Guide: NetView Management Console, GC31-8852, provides information
about the NetView management console interface of the NetView product.
v User’s Guide: Web Application, SC32-9381, describes how to use the NetView Web
application to manage complex, multivendor networks and systems from a
single point.
v Licensed Program Specifications, GC31-8848, provides the license information for
the NetView product.
v Program Directory for IBM Tivoli NetView for z/OS US English, GI10-3194, contains
information about the material and procedures that are associated with installing
the IBM Tivoli NetView for z/OS product.
xiv
Installation: Configuring Additional Components
v Program Directory for IBM Tivoli NetView for z/OS Japanese, GI10-3210, contains
information about the material and procedures that are associated with installing
the IBM Tivoli NetView for z/OS product.
v IBM Tivoli NetView for z/OS V5R4 Online Library, SK2T-6175, contains the
publications that are in the NetView for z/OS library. The publications are
available in PDF, HTML, and BookManager® formats.
Related publications
You can find additional product information on the NetView for z/OS Web site:
http://www.ibm.com/software/tivoli/products/netview-zos/
For information about the NetView Bridge function, see Tivoli NetView for OS/390
Bridge Implementation, SC31-8238-03 (available only in the V1R4 library).
Accessing terminology online
The Tivoli Software Glossary includes definitions for many of the technical terms
related to Tivoli software. The Tivoli Software Glossary is available at the following
Tivoli software library Web site:
http://publib.boulder.ibm.com/tividd/glossary/tivoliglossarymst.htm
The IBM Terminology Web site consolidates the terminology from IBM product
libraries in one convenient location. You can access the Terminology Web site at the
following Web address:
http://www.ibm.com/software/globalization/terminology/
For a list of NetView for z/OS terms and definitions, refer to the IBM Terminology
Web site. The following terms are used in this library:
|
NetView
For the following products:
v Tivoli NetView for z/OS version 5 release 4
v Tivoli NetView for z/OS version 5 release 3
v Tivoli NetView for z/OS version 5 release 2
v Tivoli NetView for z/OS version 5 release 1
v Tivoli NetView for OS/390® version 1 release 4
MVS
For z/OS operating systems
MVS element
For the BCP element of the z/OS operating system
CNMCMD
For the CNMCMD member and the members that are included in it using
the %INCLUDE statement
CNMSTYLE
For the CNMSTYLE member and the members that are included in it using
the %INCLUDE statement
PARMLIB
For SYS1.PARMLIB and other data sets in the concatenation sequence
Unless otherwise indicated, references to programs indicate the latest version and
release of the programs. If only a version is indicated, the reference is to all
releases within that version.
About this publication
xv
When a reference is made about using a personal computer or workstation, any
programmable workstation can be used.
Using NetView for z/OS online help
The following types of NetView for z/OS mainframe online help are available,
depending on your installation and configuration:
v General help and component information
v Command help
v Message help
v Sense code information
v Recommended actions
Using LookAt to look up message explanations
LookAt is an online facility that you can use to look up explanations for most of
the IBM messages you encounter, and for some system abends and codes. Using
LookAt to find information is faster than a conventional search because, in most
cases, LookAt goes directly to the message explanation.
You can use LookAt from the following locations to find IBM message
explanations for z/OS elements and features, z/VM®, VSE/ESA, and Clusters for
AIX® and Linux® systems:
v The Internet. You can access IBM message explanations directly from the LookAt
Web site at http://www.ibm.com/systems/z/os/zos/bkserv/lookat/ .
v Your z/OS TSO/E host system. You can install code on your z/OS or z/OS.e
system to access IBM message explanations, using LookAt from a TSO/E
command line (for example, TSO/E prompt, ISPF, or z/OS UNIX® System
Services running OMVS).
v Your Microsoft® Windows® workstation. You can install LookAt directly from the
z/OS Collection (SK3T-4269) or the z/OS and Software Products DVD Collection
(SK3T-4271) and use it from the resulting Windows graphical user interface
(GUI). The command prompt (also known as the DOS command line) version
can still be used from the directory in which you install the Windows version of
LookAt.
v Your wireless handheld device. You can use the LookAt Mobile Edition from
http://www.ibm.com/systems/z/os/zos/bkserv/lookat/lookatm.html with a
handheld device that has wireless access and an Internet browser.
You can obtain code to install LookAt on your host system or Microsoft Windows
workstation from the following locations:
v A CD in the z/OS Collection (SK3T-4269).
v The z/OS and Software Products DVD Collection (SK3T-4271).
v The LookAt Web site. Click Download and then select the platform, release,
collection, and location that you want. More information is available in the
LOOKAT.ME files that is available during the download process.
Accessing publications online
The documentation DVD, IBM Tivoli NetView for z/OS V5R4 Online Library,
SK2T-6175, contains the publications that are in the product library. The
publications are available in PDF, HTML, and BookManager formats. Refer to the
readme file on the DVD for instructions on how to access the documentation.
xvi
Installation: Configuring Additional Components
IBM posts publications for this and all other Tivoli products, as they become
available and whenever they are updated, to the Tivoli Information Center Web
site at http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp.
Note: If you print PDF documents on other than letter-sized paper, set the option
in the File → Print window that enables Adobe® Reader to print letter-sized
pages on your local paper.
Ordering publications
You can order many Tivoli publications online at
http://www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss
You can also order by telephone by calling one of these numbers:
v In the United States: 800-879-2755
v In Canada: 800-426-4968
In other countries, contact your software account representative to order Tivoli
publications. To locate the telephone number of your local representative, perform
the following steps:
1. Go to http://www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss.
2. Select your country from the list and click Go.
3. Click About this site to see an information page that includes the telephone
number of your local representative.
Accessibility
Accessibility features help users with a physical disability, such as restricted
mobility or limited vision, to use software products successfully. Standard shortcut
and accelerator keys are used by the product and are documented by the operating
system. Refer to the documentation provided by your operating system for more
information.
For additional information, see the Accessibility appendix in the User’s Guide:
NetView.
Tivoli technical training
For Tivoli technical training information, refer to the following IBM Tivoli
Education Web site at http://www.ibm.com/software/tivoli/education.
Downloads
Clients and agents, NetView product demonstrations, and several free NetView
applications can be downloaded from the NetView for z/OS support Web site:
http://www.ibm.com/software/sysmgmt/products/support/
IBMTivoliNetViewforzOS.html
In the ″IBM Tivoli for NetView for z/OS support″ pane, click Download to go to a
page where you can search for or select downloads.
These applications can help with the following tasks:
About this publication
xvii
v Migrating customization parameters and initialization statements from earlier
releases to the CNMSTUSR member and command definitions from earlier
releases to the CNMCMDU member.
v Getting statistics for your automation table and merging the statistics with a
listing of the automation table
v Displaying the status of a job entry subsystem (JES) job or canceling a specified
JES job
v Sending alerts to the NetView program using the program-to-program interface
(PPI)
v Sending and receiving MVS commands using the PPI
v Sending Time Sharing Option (TSO) commands and receiving responses
Support for problem solving
If you have a problem with your IBM software, you want to resolve it quickly. IBM
provides the following ways for you to obtain the support you need:
Online
Go to the IBM Software Support site at
http://www.ibm.com/software/support/probsub.html and follow the
instructions.
IBM Support Assistant
The IBM Support Assistant (ISA) is a free local software serviceability
workbench that helps you resolve questions and problems with IBM
software products. The ISA provides quick access to support-related
information and serviceability tools for problem determination. To install
the ISA software, go to http://www.ibm.com/software/support/isa/.
Troubleshooting information
For more information about resolving problems with the NetView for z/OS
product, see the IBM Tivoli NetView for z/OS Troubleshooting Guide.
Additional support for the NetView for z/OS product is available through
the NetView user group on Yahoo at
http://groups.yahoo.com/group/NetView/. This support is for NetView
for z/OS customers only, and registration is required. This forum is
monitored by NetView developers who answer questions and provide
guidance. When a problem with the code is found, you are asked to open
an official problem management record (PMR) to obtain resolution.
Conventions used in this publication
This publication uses several conventions for special terms and actions, operating
system-dependent commands and paths, and command syntax.
Typeface conventions
This publication uses the following typeface conventions:
Bold
v Lowercase commands and mixed case commands that are otherwise
difficult to distinguish from surrounding text
v Interface controls (check boxes, push buttons, radio buttons, spin
buttons, fields, folders, icons, list boxes, items inside list boxes,
multicolumn lists, containers, menu choices, menu names, tabs, property
sheets), labels (such as Tip:, and Operating system considerations:)
xviii
Installation: Configuring Additional Components
v Keywords and parameters in text
Italic
v Citations (examples: titles of publications, diskettes, and CDs
v Words defined in text (example: a nonswitched line is called a
point-to-point line)
v Emphasis of words and letters (words as words example: "Use the word
that to introduce a restrictive clause."; letters as letters example: "The
LUN address must start with the letter L.")
v New terms in text (except in a definition list): a view is a frame in a
workspace that contains data.
v Variables and values you must provide: ... where myname represents...
Monospace
v Examples and code examples
v File names, programming keywords, and other elements that are difficult
to distinguish from surrounding text
v Message text and prompts addressed to the user
v Text that the user must type
v Values for arguments or command options
Operating system-dependent variables and paths
For workstation components, this publication uses the UNIX convention for
specifying environment variables and for directory notation.
When using the Windows command line, replace $variable with %variable% for
environment variables and replace each forward slash (/) with a backslash (\) in
directory paths. The names of environment variables are not always the same in
the Windows and UNIX environments. For example, %TEMP% in Windows
environments is equivalent to $TMPDIR in UNIX environments.
Note: If you are using the bash shell on a Windows system, you can use the UNIX
conventions.
Syntax diagrams
Read syntax diagrams from left-to-right, top-to-bottom, following the horizontal
line (the main path). This section describes how syntax elements are shown in
syntax diagrams.
Symbols
The following symbols are used in syntax diagrams:
Marks the beginning of the command syntax.
Indicates that the command syntax is continued.
|
Marks the beginning and end of a fragment or part of the command
syntax.
Marks the end of the command syntax.
Parameters
The following types of parameters are used in syntax diagrams:
Required
Required parameters are shown on the main path.
Optional
Optional parameters are shown below the main path.
About this publication
xix
Default
Default parameters are shown above the main path. In parameter
descriptions, default parameters are underlined.
Syntax diagrams do not rely on highlighting, brackets, or braces. In syntax
diagrams, the position of the elements relative to the main syntax line indicates
whether an element is required, optional, or the default value.
Parameters are classified as keywords or variables. Keywords are shown in
uppercase letters. Variables, which represent names or values that you supply, are
shown in lowercase letters and are either italicized or, in NetView help and
BookManager publications, displayed in a differentiating color.
In the following example, the USER command is a required keyword parameter,
user_id is a required variable parameter, and password is an optional variable
parameter.
USER
user_id
password
Punctuation and parentheses
You must include all punctuation that is shown in the syntax diagram, such as
colons, semicolons, commas, minus signs, and both single and double quotation
marks.
When an operand can have more than one value, the values typically are enclosed
in parentheses and separated by commas. For a single value, the parentheses
typically can be omitted. For more information, see “Multiple operands or values”
on page xxi.
If a command requires positional commas to separate keywords and variables, the
commas are shown before the keywords or variables.
When examples of commands are shown, commas are also used to indicate the
absence of a positional operand. For example, the second comma indicates that an
optional operand is not being used:
COMMAND_NAME opt_variable_1,,opt_variable_3
You do not need to specify the trailing positional commas. Trailing positional and
non-positional commas either are ignored or cause a command to be rejected.
Restrictions for each command state whether trailing commas cause the command
to be rejected.
Abbreviations
Command and keyword abbreviations are listed in synonym tables after each
command description.
Syntax examples
This section show examples for the different uses of syntax elements.
Required syntax elements: Required keywords and variables are shown on the
main syntax line. You must code required keywords and variables.
xx
REQUIRED_KEYWORD
Installation: Configuring Additional Components
required_variable
If multiple mutually exclusive required keywords or variables are available to
choose from, they are stacked vertically in alphanumeric order.
REQUIRED_OPERAND_OR_VALUE_1
REQUIRED_OPERAND_OR_VALUE_2
Optional syntax elements: Optional keywords and variables are shown below the
main syntax line. You can choose not to code optional keywords and variables.
OPTIONAL_OPERAND
If multiple mutually exclusive optional keywords or variables are available to
choose from, they are stacked vertically in alphanumeric order below the main
syntax line.
OPTIONAL_OPERAND_OR_VALUE_1
OPTIONAL_OPERAND_OR_VALUE_2
Default keywords and values: Default keywords and values are shown above the
main syntax line in one of the following ways:
v A default keyword is shown only above the main syntax line. You can specify
this keyword or allow it to default. The following syntax example shows the
default keyword KEYWORD1 above the main syntax line and the rest of the
optional keywords below the main syntax line.
v If an operand has a default value, the operand is shown both above and below
the main syntax line. A value below the main syntax line indicates that if you
specify the operand, you must also specify either the default value or another
value shown. If you do not specify the operand, the default value above the
main syntax line is used. The following syntax example shows the default values
for operand OPTION=* above and below the main syntax line.
,KEYWORD1
,OPTION=*
,KEYWORD2
,KEYWORD3
,KEYWORD4
,OPTION=
COMMAND_NAME
*
VALUE1
VALUE2
Multiple operands or values: An arrow returning to the left above a group of
operands or values indicates that more than one can be selected or that a single
one can be repeated.
,
KEYWORD=( value_n
)
,
REPEATABLE_OPERAND_OR_VALUE_1
REPEATABLE_OPERAND_OR_VALUE_2
REPEATABLE_OPERAND_OR_VALUE_3
About this publication
xxi
Syntax that is longer than one line: If a diagram is longer than one line, each line
that is to be continued ends with a single arrowhead and the following line begins
with a single arrowhead.
OPERAND_1
OPERAND_6
OPERAND_2
OPERAND_7
OPERAND_3
OPERAND_4
OPERAND_8
OPERAND_5
Syntax fragments: Some syntax diagrams contain syntax fragments, which are
used for lengthy, complex, or repeated sections of syntax. Syntax fragments follow
the main diagram. Each syntax fragment name is mixed case and is shown in the
main diagram and in the heading of the fragment. The following syntax example
shows a syntax diagram with two fragments that are identified as Fragment1 and
Fragment2.
COMMAND_NAME
Fragment1
Fragment2
Fragment1
KEYWORD_A=valueA
KEYWORD_B
KEYWORD_C
KEYWORD_E=valueE
KEYWORD_F
Fragment2
KEYWORD_D
xxii
Installation: Configuring Additional Components
Chapter 1. Introduction
Using the NetView program, you can manage complex networks and systems from
multiple independent software vendors (ISVs) from a single point. This chapter is
an overview of the major components of the NetView program as they relate to the
installation and configuration steps described in this book. See Figure 1 for the
NetView host components.
Figure 1. NetView Program Host Components
Command Facility
The command facility is used to send commands and receive messages. The
command facility also provides base functions and services for other components
such as intercomponent communication, presentation services, database services,
and automation facilities.
If you want information about...
Refer to...
Installation considerations for the command
facility
“Defining the Command Facility” on page 9
© Copyright IBM Corp. 2001, 2009
1
Hardware Monitor
The hardware monitor component collects and displays events and statistical data
for both hardware and software to identify failing resources in a network. It
provides probable cause and recommended actions so that operators can perform
problem determination more efficiently.
If you want information about...
Refer to...
Installation considerations for the hardware
monitor
“Defining the Hardware Monitor” on page
33
Session Monitor
The session monitor component provides information about SNA sessions (subarea
and Advanced Peer-to-Peer Networking) including session partner identification,
session status, connectivity of active sessions, and response time data. The session
monitor also provides session trace data, route data, and Virtual
Telecommunications Access Method (VTAM®) sense code information for problem
determination.
If you want information about...
Refer to...
Installation considerations for the session
monitor
“Defining the Session Monitor” on page 36
Terminal Access Facility
The terminal access facility (TAF) provides operator control of any combination of
CICS®, IMS™, TSO, and other subsystems from one terminal. The operator does not
have to log off or use a separate terminal for each subsystem. The subsystem can
be in the same domain or in another domain.
If you want information about...
Refer to...
Defining TAF
“Defining the Terminal Access Facility” on
page 186
SNA Topology Manager
The SNA topology manager dynamically collects topology and status of Advanced
Peer-to-Peer Networking and subarea resources. This data is stored in the Resource
Object Data Manager (RODM) for display by the NetView management console.
The topology agent supplies information consisting of the SNA nodes in a
network, the Advanced Peer-to-Peer Networking transmission groups (TGs)
between them, and the underlying logical links and ports supporting the TGs, in
response to requests from the manager application.
2
If you want information about...
Refer to...
Installation considerations for the SNA
topology manager and its agent
IBM Tivoli NetView for z/OS Installation:
Configuring Graphical Components
Installation: Configuring Additional Components
4700 Support Facility
The 4700 Support Facility provides information about and management of the 47xx
Finance Communications Systems.
If you want information about...
Refer to...
Installation considerations for the 4700
support facility
“Defining the 4700 Support Facility” on page
35
Automated Operations Network
Automated Operations Network (AON) uses NetView automation facilities to
automate the monitoring and recovery of both TCP/IP and SNA network
resources. AON can monitor messages and alerts, and then automatically perform
recovery actions. AON also provides an automated help desk to assist with
resolving network problem, and generates reports so that you can monitor how
well your automation is working.
AON provides default policy definitions that enable automation, without lengthy
configuration, as soon as AON is enabled.
If you want information about...
Refer to...
Installation considerations for AON
“Defining AON” on page 43
Using AON
IBM Tivoli NetView for z/OS User’s Guide:
Automated Operations Network
MultiSystem Manager
MultiSystem Manager provides for the management of distributed resources from
the NetView program. The NetView operator can use MultiSystem Manager to
view and manage resources that are identified and managed locally by products
such as Tivoli NetView and the Tivoli framework. The topology and status of these
resources are dynamically managed through RODM and the graphical workstation
components of the NetView program.
If you want information about...
Refer to...
Installation considerations for the
MultiSystem Manager and its agents
IBM Tivoli NetView for z/OS Installation:
Configuring Graphical Components
Using the MultiSystem Manager
IBM Tivoli NetView for z/OS User’s Guide:
NetView Management Console
Browse Facility
The browse facility is used to view local or remote NetView data set members
including the NetView log, NetView parameter files, and NetView panels.
If you want information about...
Refer to...
BROWSE command
IBM Tivoli NetView for z/OS User’s Guide:
NetView
Chapter 1. Introduction
3
Automation Table
With the NetView automation table, you can specify processing options for
incoming messages and MSUs and issue automatic responses. The table contains a
sequence of statements that define the actions that the NetView program can take
in various circumstances. The automation table is one of several components that
provide automation capabilities.
If you want information about...
Refer to...
Automation
IBM Tivoli NetView for z/OS Automation Guide
Status Monitor
The status monitor component provides status information about SNA subarea
network resources.
If you want information about...
Refer to...
Installation considerations for the status
monitor
“Defining the Status Monitor” on page 21
Resource Object Data Manager
Resource Object Data Manager (RODM) is an object-oriented data cache. Objects in
RODM can represent resources in your network. The data cache is located entirely
in the memory of the host processor for fast access to data and high transaction
rates. RODM can contain approximately 2 million objects, providing support for
large and growing networks.
The MultiSystem Manager and SNA topology manager components of the
NetView program populate RODM with information such as the topology and
status of resources they monitor, and maintain that information as changes occur.
Using data in RODM, the Graphic Monitor Facility host subsystem component
dynamically builds graphical views for display by the NetView management
console. When the topology or status changes in RODM, methods automatically
update the views that include the affected resources.
Additionally, authorized operators can use the RODMVIEW command to display,
create, update, and delete classes, objects, fields, and relationships in RODM.
If you want information about...
Refer to...
Installation considerations for RODM
IBM Tivoli NetView for z/OS Installation:
Configuring Graphical Components
Graphic Monitor Facility Host Subsystem
The NetView Graphic Monitor Facility host subsystem component maintains the
status of resources in RODM and supplies the NetView Management Console with
information about RODM resources. It works with RODM and the NetView
Management Console to display graphic views of networks and to issue
commands to resources that you select from a NetView Management Console view.
The Graphic Monitor Facility host subsystem works with the SNA topology
manager and the NetView Management Console to manage SNA resources. It
4
Installation: Configuring Additional Components
works with MultiSystem Manager and the NetView Management Console to
manage non-SNA resources.
If you want information about...
Refer to...
Installation considerations for GMFHS
IBM Tivoli NetView for z/OS Installation:
Configuring Graphical Components
IBM Tivoli NetView for z/OS Enterprise Management Agent
The IBM Tivoli NetView for z/OS Enterprise Management Agent enables
management of your network from the Tivoli Enterprise Portal using sampled and
real-time data. The sampled data can provide information about network resources
and outages, using situations and expert advice. It can also indicate trends in your
network when historical data is used. Additionally, NetView, VTAM, and z/OS
commands can be issued directly from the Tivoli Enterprise Portal to provide
instant display and troubleshooting capabilities. The NetView for z/OS Enterprise
Management Agent enables management of both availability and performance data
from the Tivoli Enterprise Portal using cross-product links to selected z/OS
OMEGAMON® XE agents.
If you want information about...
Refer to...
Tivoli NetView for z/OS Enterprise
Management Agent
IBM Tivoli NetView for z/OS User’s Guide:
NetView
Subsystem Interface
The subsystem interface is used to receive system messages and to enter system
commands. With extended multiple console support (EMCS) consoles, the
subsystem interface is used to receive commands, but not messages. In a single
system, multiple NetView programs can use the subsystem interface. Each
NetView program that uses the subsystem interface requires a NetView subsystem
address space in addition to the NetView application address space.
You can use the message revision table to intercept z/OS messages before they are
displayed, logged, automated, or routed through your sysplex. With this table, you
can make decisions about a message based on its message ID, job name, and other
properties and can revise or suppress a message or take certain actions. The
message revision table is one of several components that provide automation
capabilities.
|
|
|
|
|
|
|
You can use the command revision table to intercept z/OS commands and make
simple modifications inline, without needing to transfer the command to the
NetView application address space. Commands can be deleted; parameters and
keywords can be added, removed, or modified; nicknames can be expanded (such
as creating new command or parameter synonyms); and explanatory WTO
messages can be issued. The command revision table is one of several components
that provide automation capabilities.
The program-to-program interface (PPI) is an address space provided by the
NetView program to enable application programs to communicate with the
NetView program and other applications running in the same host. When an
application calls the PPI using its application program interface (API), the request
is synchronous.
Chapter 1. Introduction
5
If you want information about...
Refer to...
PPI
IBM Tivoli NetView for z/OS Application
Programmer’s Guide
Message revision table
IBM Tivoli NetView for z/OS Automation Guide
Correlation Engine
The correlation engine correlates multiple events over time, based on duplicates,
thresholds, presence or absence of specific events, and other user-specified criteria.
The correlation engine is one of several components that provide automation
capabilities.
If you want information about...
Refer to...
Automation
IBM Tivoli NetView for z/OS Automation Guide
Installation considerations for the NetView
UNIX System Services
Chapter 12, “Setting Up UNIX System
Services for the NetView Program,” on page
201
Common Base Event Manager
Events based on the Common Base Event specification are used with the Common
Event Infrastructure to automate activities. The Common Event Infrastructure is an
IBM component technology that is used to manage events, providing a server to
store generated Common Base Events and forward them as needed.
The common base event manager serves as the intermediary between the NetView
program running under z/OS and a WebSphere® Application Server client that
interacts with the Common Event Infrastructure server. It receives Common Base
Events from the client and forwards them to the NetView program to be
automated. It receives Common Base Events created by the NetView program from
messages and MSUs and sends them to the correlation engine.
When appropriate (for example, when correlation is being bypassed or correlation
rules require submitting the event to the Common Base Event database), the
common base event manager sends a Common Base Event to the WebSphere
Application Server client, which submits the event to the database. The common
base event manager accepts connections from any number of clients for forwarding
Common Base Events to the NetView program.
If you want information about...
Refer to...
Automation using Common Base Events
IBM Tivoli NetView for z/OS Automation Guide
Installation considerations for the NetView
UNIX System Services
Chapter 12, “Setting Up UNIX System
Services for the NetView Program,” on page
201
Event/Automation Service
The Event/Automation Service (E/AS) serves as a gateway for event data between
the NetView for z/OS management environment, the Tivoli management regions,
and SNMP managers and agents. With this gateway function, you can manage all
network events from the management platform of your choice.
6
Installation: Configuring Additional Components
If you want information about...
Refer to...
Installation considerations for the
Event/Automation Service
“Enabling the Event/Automation Service” on
page 210
Installation considerations for the NetView
UNIX System Services
Chapter 12, “Setting Up UNIX System
Services for the NetView Program,” on page
201
UNIX System Services
The NetView for z/OS program uses UNIX System Services for the following
functions:
v UNIX command server
v AON/TCP functions
v Event/Automation Service
v Event correlation and the Common Event Infrastructure interface
NetView operators or programs can interact with z/OS UNIX System Services
using the PIPE UNIX stage, the IPCMD command, and the UNIX command server.
If you want information about...
Refer to...
Installation considerations for the NetView
UNIX System Services
Chapter 12, “Setting Up UNIX System
Services for the NetView Program,” on page
201
Help Facility
The NetView for z/OS mainframe online help is available for the following areas,
depending on your installation and configuration:
v General help and component information
v Command help
v Message help
v Sense code information
v Recommended actions
v Helpdesk
If you want information about...
Refer to...
Customizing help panels
IBM Tivoli NetView for z/OS Customization
Guide
Chapter 1. Introduction
7
8
Installation: Configuring Additional Components
Chapter 2. Defining NetView Components
This chapter describes setting up NetView components, including the following
topics:
v “Defining the Command Facility”
v “Defining the Status Monitor” on page 21
v “Defining the Hardware Monitor” on page 33
v “Defining the 4700 Support Facility” on page 35
v “Defining the Session Monitor” on page 36
v “Defining AON” on page 43
v “Enabling TCP/IP Connection and Packet Trace Data Collection” on page 136
Defining the Command Facility
You can customize the command facility for your environment:
v “Including Additional Task Statements”
v “Defining Command Facility Panel Format” on page 10
v “Assembling and Link-Editing the NetView Constants Module” on page 10
v “Defining Generic Automation Receiver Support” on page 16
v “Reviewing System Definitions” on page 16
v “Defining Buffer Pools” on page 17
v “Defining VSAM Performance Options” on page 20
v “Defining the MEMSTORE Function” on page 21
Including Additional Task Statements
|
|
|
If you have written any tasks besides those supplied on the distribution tape,
include the following task statements in the CNMSTUSR or CxxSTGEN member.
For information about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started.
TASK.task_name.MOD=task_module
TASK.task_name.MEM=task_init_member
TASK.task_name.PRI=task_priority
TASK.task_name.INIT=initialize_task(Y/N)
where task_name is the name of your task. Replace the other variables in the
statements with information to define your task to the NetView program.
If a task you have written uses VSAM, allocate the VSAM data sets. If the
parameter that defines the task contains a DSTINIT statement specifying
FUNCT=CNMI or FUNCT=BOTH, add a VTAM APPL statement to A01APPLS
(CNMS0013).
If you want information about...
Refer to...
Designing functions
IBM Tivoli NetView for z/OS Customization
Guide
Writing your own user subtasks
IBM Tivoli NetView for z/OS Programming:
Assembler
TASK statement and reserved task names
IBM Tivoli NetView for z/OS Administration
Reference
© Copyright IBM Corp. 2001, 2009
9
Defining Command Facility Panel Format
CNMSCNFT lets you define the screen colors, prefix data, and prefix display order
for message formatting. The SCRNFMT keyword on the DEFAULTS command
specifies the beginning of the screen format definitions. The OVERRIDE command
also has a SCRNFMT keyword for overriding the current screen format definitions.
Each set of SCRNFMT definitions results in a complete replacement of all values
for all attributes. If you do not code any operands, the NetView default values are
used.
If you want information about...
Refer to...
The definition statements
IBM Tivoli NetView for z/OS Administration
Reference
Customizing the NetView command facility
panel
IBM Tivoli NetView for z/OS Customization
Guide
Assembling and Link-Editing the NetView Constants Module
The NetView constants module, DSICTMOD, contains timeout values for various
NetView functions. The constants module also contains values for storage sizes,
sense codes, and storage management performance options.
The CNMS0055 job assembles and link-edits the module. Run this sample to
change the NetView default values for the constants described in this section.
You can modify the module using a system service aid, such as AMASPZAP, or
replace it by reassembling DSICTMOD using CNMS0055. Your new copy of
DSICTMOD must reside in a user-defined library that is concatenated before
NETVIEW.V5R4M0.CNMLINK in your NetView start procedure CNMPROC
(CNMSJ009). Whenever you modify values in DSICTMOD or replace the module,
restart the NetView program to activate the new values.
Boundary Function Trace Initialization Timeout
If the session monitor is started with the TRACE function active, it sends a TRACE
data request to each PU type 4 node after becoming aware of it through session
awareness (SAW) data. After the request is sent, the session monitor waits for the
response. If it does not receive a response within the specified time, message
AAU114I is sent to the authorized receiver.
The default value is 180 seconds.
Connectivity Test Timeout
The connectivity test is selected from the Session List panel of the session monitor.
Each test can consist of one or more route test requests. For each route test request,
the session monitor waits for the response. If it does not receive a response within
the specified time, the entire connectivity test fails. Message AAU114I is sent to the
authorized receiver and message AAU947I is sent to the operator who requested
the test.
The default value is 180 seconds.
Gateway TRACE Initialization Timeout
If the session monitor is started with the TRACE function active, it sends a
gateway (GW) TRACE data request to each GW after becoming aware of it
through SAW data. After the request is sent, the session monitor waits for the
10
Installation: Configuring Additional Components
response. If it does not receive a response within the specified time, message
AAU114I is sent to the authorized receiver.
The default value is 180 seconds.
Gateway Boundary Function Trace Request Timeout
When GW TRACE data is requested for display, the session monitor sends a
request to GW NCP for TRACE data. If it does not receive a response within the
specified time, the session monitor sends message AAU114I to the authorized
receiver and message AAU947I to the operator who made the request.
The default value is 180 seconds.
LINEMAP Command Timeout
The session monitor LINEMAP command issues a line map request to the
destination PU. The session monitor waits for a response. If it does not receive a
response within the specified time, message AAU114I is sent to the authorized
receiver and message AAU947I is sent to the operator who issued the request.
The default value is 180 seconds.
NCP Boundary Function Trace Data Request Timeout
A boundary function trace request is sent every time an operator requests a
boundary function trace display. The session monitor waits for a response. If it
does not receive a response within the specified time limit, the session monitor
sends message AAU114I to the authorized receiver and message AAU947I to the
operator requesting the display.
The default value is 180 seconds.
Nonpersistent Sessions Timeout Value
The timeout interval specifies, in seconds, the time between messages during
which a nonpersistent session stays active. If the time between conversations is
greater than this amount, the session ends. If you do not change the default value
of 0, and the LUC session is nonpersistent, message DSI624I is issued and the
session is persistent.
The default value is 000 seconds.
Query PSID Request Timeout
If the session monitor is started with the TRACE function active, the session
monitor sends a QUERY PSID request to each subarea node for its release level.
After the request is sent, the session monitor waits for a response. If it does not
receive a response within the specified time, the session monitor sends message
AAU114I to the authorized receiver.
The default value is 180 seconds.
Route Test Initialization Timeout
The session monitor issues a route test request for each new route it knows of
through SAW data. The route test is issued with a time limit. If the response to the
test request is not received within the specified time, the session monitor sends
message AAU114I to the authorized receiver.
The default value is 180 seconds.
Chapter 2. Defining NetView Components
11
RTM Collection Request Timeout
When an operator issues the COLLECT RTM command, the session monitor sends
a message to the operator to indicate successful start of the command. For each
destination PU located, the command processor then drives another process in the
session monitor to send an RTM data request. The PU sends RTM data to the
session monitor in response to that request. If it does not receive the data within
the specified time, the session monitor sends message AAU114I to the authorized
receiver.
The default value is 180 seconds.
RTM Initialization Request Timeout
To determine the RTM capabilities of a device, an NMVT RU is sent to the PU.
RTM INIT specifies the amount of time allowed for the PU to respond.
The default value is 180 seconds.
Service Point Control Interface Commands Timeout
This is the timeout value for a command to complete to a service point. If the
command does not respond in this interval, it is canceled. Provide appropriate
timeout values to prevent commands to service points from restricting the use of
critical resources (such as DSRBs) when the command fails.
Use this constant to set the default for the COSTIME keyword on the NetView
DEFAULTS command. The minimum value is 0, which specifies that the timeout
value is determined by the value on the DEFAULTS RCVREPLY keyword.
X'FFFFFFFF' specifies that the timeout value is determined by the DEFAULTS
MAXREPLY keyword. The maximum value is the value assigned to the DEFAULTS
MAXREPLY keyword.
If you want information about...
Refer to...
The DEFAULTS command and its keywords
IBM Tivoli NetView for z/OS Command
Reference Volume 1 (A-N)
TRACE NCP Command Timeout
The session monitor sends an NCP TRACE START/END request in response to the
TRACE START/STOP command. The NCP processes the request and sends a
response back to the session monitor. If it does not receive a response within the
specified time, the session monitor sends message AAU114I to the authorized
receiver and message AAU947I to the operator who issued the TRACE command.
The default value is 180 seconds.
VR Status Request Timeout
In response to a route status request from an operator, the session monitor sends a
request for route status data. If it does not receive a response within the specified
time, the session monitor sends message AAU114I to the authorized receiver. A
timeout condition does not cause the entire route status request to fail. Thus, the
requesting operator can receive a partial route status display or a data service
failure message.
The default value is 180 seconds.
12
Installation: Configuring Additional Components
Hardware Monitor Remote Data Retrieval Timeout
An operator at a focal point is logged on to the NetView program and wants to
obtain detailed data about an event that generated an alert. The operator issues a
request to the distributed host. If the response is not received within the specified
time, the operator receives a timeout notification. This timeout is also used for a
FOCALPT CHANGE command to change an alert focal point using LU
conversation (LUC).
The default value is 120 seconds.
Hardware Monitor Solicited Commands Timeout
This is the timeout value for all hardware monitor and 4700 support facility
solicited commands. The following commands are timed by the hardware monitor
timeout value:
v NPDA TEST
v NPDA CTRL
v TARA SET PARM
v SOLICIT
v SYSMON
v REQMS
On timeout, messages BNJ093I and BNJ992I are sent to NPDA TEST, NPDA CTRL,
and TARA SET PARM. BNJ093I is a component message line, and BNJ992I is sent
to the authorized receiver. SOLICIT, SYSMON, and REQMS commands receive
message BNJ992I on timeout, and the message is sent to the authorized receiver.
The default value is 180 seconds.
HLL Default Stack Size
The STACK runtime option is used for PL/I dynamic storage allocation.
|
|
|
|
You can use the HLLENV statement (PSTACK keyword) in the CNMSTUSR or
CxxSTGEN member to preinitialize the HLL environment. The default value for
PSTACK is 131072 bytes. For information about changing CNMSTYLE statements,
see IBM Tivoli NetView for z/OS Installation: Getting Started.
HLL Default HEAP Area
HEAP specifies storage that is used to allocate controlled and based variables. It
also specifies how that storage is to be managed.
|
|
|
|
You can use the HLLENV statement (PHEAP keyword) in the CNMSTUSR or
CxxSTGEN member to preinitialize the HLL environment. The default value for
PHEAP is 131072 bytes. For information about changing CNMSTYLE statements,
see IBM Tivoli NetView for z/OS Installation: Getting Started.
Task Public Message Queue Thresholds
The following group has three pairs of threshold values. Each pair consists of a
task threshold value and a reissue threshold value. Table 1 on page 14 shows the
threshold values for the groups. When the number of buffers in the public message
queue exceeds the task threshold value for a particular type of task, message
DSI374A is issued. This condition can indicate that the buffers on the public
message queue are not being processed. Message DSI374A is issued thereafter
every time the reissue threshold is exceeded. For example, if the task is an OST,
DSI374A is issued if the number of buffers in the public message queues exceeds
1000. Message DSI374A is reissued when the count reaches 1100, 1200, 1300, and so
on.
Chapter 2. Defining NetView Components
13
Table 1. Thresholds for Task Types
Task Type
Default Threshold
Default Reissue Threshold
PPT
1000
100
OST/AUTO
1000
100
DST/OPT/HCT
3000
500
Maximum Number of APPCCMD Retries
The APPCCMD retries constant specifies the maximum number of times that the
NetView program attempts to issue an LU 6.2 command to the NetView
management console server. Note that the command might fail because of a
temporary error. Only those errors that VTAM defines as temporary are eligible to
be retried.
The default value is three times.
Entry for LU 6.2 Transport Support
This constant specifies the maximum number of LUs with which the MS transport
function or high performance transport function can be expected to have sessions.
Changing this constant changes the size of the internal tables used by the transport
functions, and can affect storage used by the transport functions.
The default value is 2000 LUs.
Timeout Value for CSCF
This constant specifies the number of seconds the NetView program waits for a
reply when a central site control facility (CSCF) request is sent to the target
physical unit (PU). If a reply is not received from the PU within the specified
number of seconds, a timeout occurs and the CSCF session is stopped. Certain
commands issued on the requested PU can take several seconds to complete and
can directly relate to the characteristics of that PU. Be sure to adjust this timeout
value appropriately to accommodate both communication errors, which can result
in no reply for a given request, and PU commands, which can take several seconds
to run and return a reply.
The default is 30 seconds.
CSCF Application Idle Timeout
This constant is the number of minutes that a CSCF session is allowed to remain
active in the NetView system without an operator having any interaction with the
PU with which the operator is in session. Each time CSCF interacts with the PU in
any way (for example, an attention key or command entered on the command line
is passed to the PU), the timer is reset to this number of minutes. If an operator
has no interaction with the PU for this number of minutes, a timeout occurs and
the NetView program ends the session. This timeout is allowed because there can
be only one CSCF session for each PU at any time. If an operator establishes a
CSCF session with a PU, no other operators can have a CSCF session with that PU
until the active session ends.
The default value is 20 minutes.
Storage Management Performance
This field determines whether NetView storage management keeps the first
allocation of storage below the 16 Mb line for an individual subpool and size when
it is no longer in use. If the storage is not freed, NetView performance is enhanced,
14
Installation: Configuring Additional Components
while below-the-line storage use is increased. If the storage is freed, performance
during later requests for below-the-line storage is slower, but storage use is
smaller.
The default, X'00', keeps below the line storage.
Note: If you have less than 300 users logged on at any one time, or if you have a
large amount of user-written code that runs below-the-line, use the default.
Automation Table Loading
This field determines whether an automation table successfully loads if commands
or command lists that are called out of the automation table are missing. If a
command or command list is missing, an error message is issued, regardless of
how this field is set. If you set the byte to X'01' and errors other than the missing
commands or command lists do not occur, the table you specified on the
AUTOTBL command is activated and replaces the current active automation table
in storage.
The default is X'00' (missing commands and command lists prevent the automation
table from loading).
RTM Initialization Retry and Interval
Use this field to specify the maximum number of retries and the number of
seconds between each try for the response time monitor.
The default is 5 retries with 60 seconds between each try.
Expected Number of Task Global Variables
By specifying the number of task global variables you expect to use, you can
improve the access time for retrieving task global variables.
You can use the QRYGLOBL command to determine the total number of task
global variables currently defined by each task.
The default is 100 variables.
If you want information about...
Refer to...
Storage requirements
IBM Tivoli NetView for z/OS Tuning Guide
Expected Number of Common Global Variables
By specifying the number of common global variables you expect to use, you can
improve the access time for retrieving common global variables.
The QRYGLOBL command can be used to determine the total number of common
global variables currently defined. Depending on which AON components and
functions you are using, you might want to increase this number.
|
|
|
|
Note: You can also update the COMMON statement to set common global
variables in the CNMSTUSR or CxxSTGEN member. The variables are set
before any autotasks are started and before automation is enabled. For
information about changing CNMSTYLE statements, see IBM Tivoli NetView
for z/OS Installation: Getting Started.
Chapter 2. Defining NetView Components
15
If you want information about...
Refer to...
QRYGLOBL command
IBM Tivoli NetView for z/OS Command
Reference Volume 1 (A-N)
Sense Code Filtering
You can modify session monitor sense code filtering. For more information, see
“Adding a Sense Code for Filtering” on page 39 and “Stopping Sense Code
Filtering” on page 40.
Defining Generic Automation Receiver Support
The generic automation receiver allows an MDS-MU to be sent to a NetView
system with the generic automation receiver. The generic automation receiver then
submits the MDS-MU to NetView automation.
CNMCMSYS contains the following command definition statements. These
statements are required to start the generic automation receiver support in the
NetView program:
CMDDEF.DSIREGGR.MOD=DSIREGGR
CMDDEF.DSIREGGR.SEC=BY
CMDDEF.DSILOGGR.MOD=DSILOGGR
CMDDEF.DSILOGGR.SEC=BY
CMDDEF.DSINVGRP.MOD=DSINVGRP
CMDDEF.DSINVGRP.PARSE=N
CMDDEF.DSINVGRP.RES=N
CMDDEF.DSINVGRP.SEC=BY
If you expect use of the generic automation receiver to be heavy, add the following
CMDDEF to CNMCMDU:
CMDDEF.DSINVGRP.RES=Y
You can define the generic automation receiver as its own task by issuing the
following command:
'AUTOTASK OPID=DSINVGR'
Note: Consider adding this command to the CNMSTUSR or CxxSTGEN member
so that it is issued at NetView initialization. For information about changing
CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation: Getting
Started.
|
|
|
|
This statement points to the following operator statement in DSIOPF in the
DSIPARM data set:
DSINVGR
OPERATOR
PROFILEN
PASSWORD=GENREC
DSIPRFGR
The generic automation receiver also uses the following profile statement in
DSIPRFGR in the DSIPRF data set:
DSIPRFGR
PROFILE IC=DSIREGGR
AUTH
MSGRECVR=NO,CTL=GLOBAL
Reviewing System Definitions
Review and adjust the system parameters by preparing a message processing
facility (MPF) list that blocks unnecessary messages sent to the NetView program
for automation. This can have a significant effect on performance if you are using
NetView automation.
16
Installation: Configuring Additional Components
Note: Do not send messages that are not automated to the NetView program. Each
message that the NetView program receives causes a search of the
automation table.
Defining Buffer Pools
Use job CNMSJM01 in NETVIEW.V5R4M0.CNMSAMP to define your buffer pools.
The VSAM local shared resources (LSR) performance option is the sharing of
common control blocks, such as input/output (I/O) control blocks, buffers, and
channel programs. When running the NetView program, LSR is the default. LSR
also causes VSAM to search buffers for direct record retrievals. Without LSR,
VSAM carries out I/O for direct retrievals regardless of whether the control
interval containing the record you want is in storage.
Deferred write (DFR) option causes VSAM to defer the write I/O action when
records are directly inserted or replaced in direct mode. Without DFR, VSAM does
not defer the I/O for direct inserts or replacements of records. With DFR, the
buffers are written in these instances:
v When no more buffers are available to do a retrieve
v When the application issues the WRTBFR macro indicating that VSAM is to
write out the modified buffers
v When the database is closed
If the NetView program stops without closing the databases, the records in the
DFR buffers are not written to the databases.
With the LSR or DFR options, VSAM uses a resource pool for buffering. The
NetView program creates this resource pool during initialization when the
NetView program issues the VSAM BLDVRP macro. The resource pool is divided
into buffer pools based on the VSAM control interval (CI) sizes passed to the
BLDVRP macro in the BLDVRP parameter list. For the NetView program, the
DSIZVLSR module is the BLDVRP parameter list that is passed to the BLDVRP
macro. By using the resource pool, you can show VSAM how many and what size
buffers to allocate. This resource pool is in extended storage.
Note: Run CNMSJM01 to link-edit the DSIZVLSR module.
The BLDVRP macro has been specified with values that separate the index and
data control intervals into separate pools. Separating the INDEX and DATA
intervals allows the critical index records to remain resident in memory without
having to allocate an excessive number of buffers. The VSAM index and data
control interval sizes have been selected so that similar function share-pool sizes
reduce contention.
Buffer Pool Sizes
When you open a database and specify LSR or DFR, VSAM looks for a buffer pool
for the INDEX and DATA components, depending on their control interval sizes. A
buffer pool that is the same size as the control interval size is chosen. If a buffer
pool with the same size has not been defined, the next higher buffer pool size is
chosen. If compatible buffer pools are not defined, the open fails with a VSAM
error code of X'DC'. If no resource pool is defined, the open fails with a VSAM
error code of X'E4'. Databases with the same control interval sizes share the same
buffer pool. Allocate enough buffers of a particular size to satisfy all users sharing
the buffer pool.
Chapter 2. Defining NetView Components
17
VSAM performance is affected by the buffer allocations. Use the DSIZVLSR
module to specify the size and number of buffers to allocate.
Changes to the following parameters for defining clusters can affect the values
specified for the LSR pool built by CNMSJM01. If these values are modified, refer
to the IBM Tivoli NetView for z/OS Tuning Guide to verify that the parameters
specified for the LSR pool are still valid.
v CONTROLINTERVALSIZE (CISZ)
v CYLINDERS
v KEYS
v KILOBYTES
v MEGABYTES
v RECORDS
v TRACKS
The operands specified in the examples have been selected based on using an IBM
3390 DASD (using ICF catalogs). If other types of devices are used to allocate these
clusters, these operands might need to be adjusted for optimal use of the device.
For 3380 DASD, refer to the IBM Tivoli NetView for z/OS Tuning Guide for CISIZE
recommendations.
If you use the recommended VSAM cluster definitions, the buffer sizes in
CNMSJM01 are required.
Note: Values in CNMSJM01 reflect the number of bytes recommended for each
VSAM buffer size.
Minimum Buffer Allocations
Use the following formulas to determine the minimum number of buffers you
need to define for the INDEX and DATA pools for each NetView VSAM data
services task (DST).
v INDEX buffers: allocate (2 X DSRBO + 2)
v DATA buffers: allocate (DSRBO + 3)
Note: DSRBO is a DSTINIT parameter for NetView VSAM DST initialization
members. The DSRBO parameter shows how many consecutive VSAM
requests, operator requests, or both, can be scheduled. For an example, see
AAUPRMLP (session monitor) and BNJMBDST (hardware monitor)
initialization members.
Define one INDEX buffer for each DSRBO and one additional INDEX buffer for
control interval splits and for the highest level INDEX.
Define one DATA buffer for each DSRBO and three additional DATA buffers for
control interval splits and control area splits.
Additional Buffer Allocations
Consider the following information to determine how many additional buffers you
can define for INDEX and DATA for each VSAM DST:
v Allocate enough INDEX buffers to get the entire INDEX in storage, plus two
additional buffers.
Note: The IDCAMS LISTCAT command or the NetView LISTCAT command
displays the number of index records. Start with 20 INDEX buffers and
then monitor.
18
Installation: Configuring Additional Components
v Allocate enough DATA buffers so VSAM can read an entire hard disk drive
track of control intervals for each DSRBO specified. In sequential mode, VSAM
reads ahead an entire track of data if enough buffers are available.
For example, the session monitor has a 24.5K data control interval (CI), and a
3390 DASD has a 56K track size. Therefore, two CIs can fit on one track.
Multiplying the number of CIs for each track by the session monitor DSRBO
(default of 10) gives you 20 DATA buffers.
v The MACRF=DFR statement uses the LSR and DFR VSAM options to reduce the
number of I/O accesses to the VSAM database by the hardware monitor. All
VSAM buffers used by the hardware monitor are 18.4K. The hardware monitor
is the only DST to use buffers from this size pool. Therefore, the global buffer
definitions in the DSIZVLSR CSECT need to allocate enough 18.4K buffers for
the hardware monitor. Calculate the number of buffers needed using the
formula:
((2 X DSRBO value) + 3)
For example, if your DSRBO value is 5, use:
((2 x 5) + 3)
to give you a required total of 13 buffers.
v Experiment with additional buffers on larger systems. However, allocating
excessive buffers can degrade performance. Eventually it takes VSAM longer to
find a record in a buffer than it does to read it. Monitor the processor utilization,
paging, real storage, hard disk drive utilization, and the NetView program
response time when experimenting with buffer sizes.
Note: The NetView VSAMPOOL command displays VSAM buffer pool
allocation and usage.
Changes to CNMSJM01
Use the VSAM LSR performance option to increase the efficiency of record
processing.
To use the VSAM LSR performance option:
1. Edit CNMSJM01.
The DSIZVLSR CSECT contains two LSR Pools. The first pool defines resources
for the DATA component. The second pool defines resources for the INDEX
component.
See “Minimum Buffer Allocations” on page 18 for information about selecting
the proper values for the BUFFERS keyword.
Refer to the IBM Tivoli NetView for z/OS Tuning Guide for a detailed example on
determining tuned values for the LSR pools.
Allocate at least two buffers for each DSTINIT statement that uses MACRF=LSR or
MACRF=DFR. Of these two buffers, one is used for index records and the other is
used for the data records. Use the CISIZE information found in the VSAM
catalog for the index and data components to select appropriate buffer sizes.
Also, allocate enough buffers to store most (or all) index records.
Refer to IBM Tivoli NetView for z/OS Tuning Guide for additional information
concerning how to calculate your buffer values.
2. Run CNMSJM01 to allocate and link-edit the DSIZVLSR CSECT.
3. Ensure that the return code is 0 before proceeding to the next step.
4. Your new copy of DSIZVLSR must reside in a user-defined library that is
concatenated before NETVIEW.V5R4M0.CNMLINK in your NetView start
Chapter 2. Defining NetView Components
19
procedure CNMPROC (CNMSJ009). Whenever you modify values in
DSIZVLSR or replace the module, restart the NetView program to activate the
new values.
Defining VSAM Performance Options
Two VSAM performance options, LSR and DFR, can be defined for NetView
VSAM DSTs to improve VSAM processing and reduce I/O and storage.
LSR is the sharing of common control blocks such as I/O control blocks, buffers,
and channel programs. LSR also causes VSAM to search buffers for direct record
retrievals. Without LSR, VSAM carries out I/O for direct retrievals regardless of
whether the control interval containing the preferred record is in storage.
DFR causes VSAM to defer the write I/O when records are directly inserted or
replaced in direct mode. Without DFR, VSAM does not defer the I/O for direct
inserts or replacement of records. With DFR the buffers are written in these
instances:
v When no more buffers are available to do a retrieve
v When the application issues the WRTBFR macro indicating that VSAM is to
write out the modified buffers
v When the database is closed
If the NetView system stops without closing the databases, the records in the DFR
buffers are not written to the databases. The exposure is minimized by the
extended specify task abnormal exits (ESTAEs) that trap abends and close the
databases. However, if the system operator stops the NetView program with the
MVS FORCE command, the ESTAEs are not driven. Do not cancel the NetView
program, except as a last resort. If you issue a FORCE command, try to close the
databases by issuing the NetView SWITCH command with the T option. This does
not perform a switch; it just closes the active database. If this procedure does not
work, issue the NetView STOP FORCE command for each active VSAM task. If
you use the MVS FORCE command to bring down the NetView system and you
have specified DFR, you might have to delete and redefine the affected databases.
If you specify DFR, you get both the LSR and DFR options.
LSR and DFR values are defined with the DSTINIT statement:
DSTINIT MACRF=xxx
Where:
LSR
Specifies that the LSR option is used for VSAM performance.
DFR Specifies that DFR option is used for VSAM performance.
Table 2 lists the DFR and LSR values for the NetView components and facilities.
Table 2. LSR and DFR Values for NetView Facilities and Components
20
Component
Member
Value
Central site control facility
DSIKINIT
Specify LSR
Hardware monitor
CNMSTYLE
Specify LSR
Network log
DSILOGBK
Do not specify DFR or LSR
Save/restore database
DSISVRTD
Specify LSR
Session monitor
CNMSTYLE
Specify LSR
Installation: Configuring Additional Components
Table 2. LSR and DFR Values for NetView Facilities and Components (continued)
Component
Member
Value
4700 support facility
BNJ36DST
Specify LSR
TCP/IP Connection Management
CNMSTYLE
Specify LSR
Defining the MEMSTORE Function
|
To improve NetView performance and reduce disk I/O, you can let NetView
monitor its access of PDS members and keep high-access members in storage. The
NetView program includes a MEMSTORE CLIST (CNME1054). The NetView
program is shipped with MEMSTORE enabled in the CNMSTYLE member.
Note that operators can see the members loaded in storage by using the BROWSE
and LIST commands. For more information, refer to the IBM Tivoli NetView for
z/OS Programming: Pipes.
|
|
|
Note: The memStore statements in the CNMSTYLE member specify the thresholds
for automatic retention of members in storage. The inStore statements in the
CNMSTYLE member specify the members that are to remain in storage
regardless of their usage. You can use the RESTYLE MEMSTORE command
to enable changes without recycling the NetView program.
Defining the Status Monitor
With the status monitor, you can perform activities such as the following activities:
v Process command lists
v Provide status information for automated recovery of failing devices
v Specify the initial status for resources not known to VTAM
This section describes how to define the status monitor to suit your requirements.
Note: The status monitor monitors only the SNA resources that were defined in
the VTAMLST data sets when you started the NetView program. You can
use the NetView management console to dynamically discover and monitor
resources (both SNA and IP). The NetView management console also
provides a graphical interface. For more information, refer to IBM Tivoli
NetView for z/OS Installation: Configuring Graphical Components.
Processing Command Lists from the Status Monitor
You can process command lists from the Status Detail panels of the status monitor.
These are ordinary command lists that can be processed without any operands or
with the node name as the only operand. The following command lists are
supplied in DSICNM:
C
C
C
C
C
C
C
C
C
C
C
AUTOTR
NODE
EVENTS
INACTF
MONOFF
MONON
RECYCLE
REDIAL
SESS
STATIONS
STATS
Chapter 2. Defining NetView Components
21
The C is in position 1 and the command list name starts in position 3. You can add
command lists to the existing set of lists or you can replace them with those that
you define. A maximum of 16 command lists is allowed.
If you want information about...
Refer to...
The C statement
IBM Tivoli NetView for z/OS Administration
Reference
Specifying the Designated Interface with VTAM
The following statement in DSICNM specifies that the status monitor of this
NetView system runs as a secondary network resource status monitor and does not
receive unsolicited messages from VTAM:
* O SECSTAT
Use this statement if you have more than one active NetView status monitor. O
SECSTAT is commented out in DSICNM. Uncomment this statement for the status
monitor that is not monitoring the network’s status.
The O (letter O, not zero) is in position 1 and the SECSTAT starts in position 3. If
you want to run the status monitor with the primary interface to receive
unsolicited messages, either leave this statement commented out, or delete it.
If you do not specify O SECSTAT, the first status monitor initialized is given the
network status updates from VTAM.
If you code O SECSTAT in multiple NetView programs in one LPAR, neither one
receives the updates from VTAM. For more information, see Appendix A,
“Running Multiple NetView Programs in the Same LPAR,” on page 231.
Specifying the Automatic Reactivation of Failing Nodes
The following statement in DSICNM specifies that failing nodes can be reactivated
if they are defined for reactivation by a STATOPT statement:
O MONIT
The O (alphabetical O, not zero) is in position 1 and the MONIT starts in position 3.
If you do not want this feature, delete this statement.
Note: Disable the O MONIT statement if you are using AON to automate your SNA
resources.
The following statement in DSICNM can be used to specify the maximum number
of times that the status monitor MONIT function is to activate a particular
resource:
M MAXREACT
00
The default value is 00, which means that an unlimited number of activation
attempts are made for the resource. The value specified applies to all resources
monitored by the status monitor. Maximum reactivation counters for resources are
set to zero at status monitor initialization.
Note: The value specified is used to limit the number of times the status monitor
accepts a resource for reactivation by the MONIT function and does not
limit the number of reactivation attempts made for the resource after it is
accepted by the MONIT function for reactivation.
22
Installation: Configuring Additional Components
The following statement in DSICNM can be used to specify a time interval for the
MONIT function reactivation attempts:
M REACTINT
00
The time interval is specified in minutes. The default value is 00, which means that
reactivation attempts for resources is made at 1-minute intervals. The value
specified applies to all resources monitored by the status monitor.
Modifying the Message Indicator Settings
VTAM, MVS, JES, and NetView messages and responses are recorded in the
network log. You can assign panel color codes, highlighting, and alarms to show to
an operator when certain messages occur.
To emphasize a message, use message alert settings (A statements) in DSICNM.
For example, if you specify A3 PYBYN, the following alert settings are used for
message indicator 3:
P
The alert is colored pink.
Y
The alert indicator is set on authorized receiver.
B
The alert blinks.
Y
The alarm sounds when the alert is received.
N
A copy of the unsolicited message is not sent to the system console.
For more information, refer to IBM Tivoli NetView for z/OS Administration Reference.
Providing Status Information for Automated Recovery of
Failing Devices
You can automate message CNM094I using NetView automation to provide
automatic reactivation of failing resources. The SENDMSG statement specifies the
resource types for which the NetView program issues message CNM094I when
those resources change status. Message CNM094I provides status information for
all resources defined to the status monitor.
Note: If a resource has several status changes in rapid succession, CNM094I might
not be issued for the intermediate statuses.
Use the SENDMSG statement to specify each type of resource for which you need
additional status information.
The following statements are valid SENDMSG statements in DSICNM:
*SENDMSG
*SENDMSG
*SENDMSG
*SENDMSG
*SENDMSG
*SENDMSG
*SENDMSG
*SENDMSG
*SENDMSG
*SENDMSG
*SENDMSG
*SENDMSG
*SENDMSG
*SENDMSG
*SENDMSG
*SENDMSG
HOST
NCP/CA MAJOR NODES
LINES
PUS/CLUSTERS
LUS/TERMINALS
SWITCHED MAJOR NODES
SWITCHED PUS
SWITCHED LUS
XCA MAJOR NODES
XCA LINES
XCA PUS
LOCAL SNA MAJOR NODES
LOCAL PUS
LOCAL LUS/TERMS
APPL MAJOR NODES
APPLICATIONS
Chapter 2. Defining NetView Components
23
*SENDMSG
*SENDMSG
*SENDMSG
*SENDMSG
CDRM MAJOR NODES
CDRMS
CDRSC MAJOR NODES
CDRSCS
The O SENDMSG statement specifies that the NetView program is to issue
message CNM094I at status monitor initialization for the resource types specified
on the SENDMSG statement.
The SENDMSG statement must start in column 1 and the resource type must start
in column 9.
Code a SENDMSG statement for each resource type for which you need additional
status information.
Note: You cannot specify individual resources on the SENDMSG statement. You
can only specify a resource type.
To avoid degradation of system performance, carefully select the type of resources
for which you want status information.
If you request additional information about a resource type and if your network
has many instances of that resource type, the status monitor issues many
corresponding CNM094I messages, which can slow down the system
You can use CNM094I with NetView automation and the NetView management
console to enhance the recovery of resources in your network. The automation
table entry for this message in DSITBL01 suppresses the display and logging of
this message.
Specifying the Initial Status for Resources Not Known to
VTAM
The following statement in DSICNM specifies whether the status monitor sets an
initial status of RESET for any resources that are known to the status monitor but
are unknown to the VTAM associated with the status monitor:
* O RESET
Uncomment this statement for any status monitor that sends status to the SNA
topology manager to enable the SNA topology manager to resolve the status of
multiply owned resources. The O must be coded in position 1 and the RESET must
be coded in position 3.
If you do not specify O RESET, the status monitor sets an initial status of NEVER
ACTIVE for all resources not known to the VTAM associated with this status
monitor. If this status monitor sends status to the SNA topology manager, the SNA
topology manager might not be able to resolve the status of these resources.
Defining SNA Resources to the Status Monitor
In the status monitor, you can assign a descriptive name to each resource or node.
This helps the operations staff better understand the network they control, which
reduces the education needed and the time required to quickly identify and correct
a problem in the network. The status monitor can also increase node availability by
automatically reactivating failed nodes when possible.
24
Installation: Configuring Additional Components
The status monitor helps control network nodes and display their status. It groups
the resources of your network into major and minor node categories the same way
they are defined in the VTAM definitions. The approach the status monitor takes in
structuring its view of the network is similar in concept and nomenclature to that
used by VTAM. The following terms used by the status monitor have the same
meanings as they do in VTAM:
Resource
A generic term for any named entity defined to VTAM.
Node
A generic term for resource, but it implies a hierarchical
relationship.
Major node
An aggregate of minor node definitions represented by a VTAM
definition data set member.
Minor node
A resource in a VTAM definition within a major node.
Defining the Nodes
Before the status monitor can monitor a network in the domain where it runs,
define the nodes that constitute the network and the relationships between these
nodes. Each minor node must belong to a major node. Generally duplicate node
names are not used.
The following are some exceptions for which it might be feasible to use duplicate
names:
v When defining CDRSC/APPL LUs, the preprocessor checks the resource if the
CDRSC was a duplicate of an APPL. For example, you might want to define a
CDRSC for one host system by the same name as an APPL LU for another host
system.
v Switched LU names can be duplicated under two different major node names.
v Switched LU names and nonswitched LU names can be duplicates of each other.
If duplicate resource names are found, the preprocessor puts a warning message in
the print member and sends a return code of 4.
The network definition is held in DSINDEF. This data set member is created by
program CNMNDEF (CNMSJ007), which is the status monitor preprocessor. The
input to this program comes from the major nodes (VTAM definition members)
that together define the total network nodes of the domain where the status
monitor is running.
Notes:
1. The status monitor preprocessor detects resources that are in the VTAMLST
data sets but are not known to VTAM. These resources are still placed in
DSINDEF but are automatically omitted from monitoring during status monitor
initialization.
2. The status monitor recognizes a maximum of 999999 resources, including the
host. If you have more than this number of resources defined to VTAM, code
STATOPT=OMIT for some of your resources or define a subset of your
VTAMLST resources as the input member to the status monitor preprocessor. If
you do not limit your resources to 999999, a message is issued during NetView
initialization, and only the first 999999 resources are known to the status
monitor. The host is considered a resource; therefore STATMON panels show a
maximum of 999998 resources. The host name is displayed in the upper left
corner of the panel.
3. You can modify the VTAMLST to monitor an independent LU. Remove the
independent LU from under its associated PU and add it underneath a
Chapter 2. Defining NetView Components
25
cross-domain resource (CDRSC) major node. For example, suppose your
independent LU was previously defined in the following way:
A01L01
LINE
A01P2A0
PU PUTYPE=2
A01A2L01 LU LOCADDR=0
It is now defined under a CDRSC major node with its associated PU name, as
shown in the following example:
A01A2L01
VBUILD
TYPE=CDRSC
CDRSC ALSLIST=(A01P2A0)
If you do not modify the VTAMLST, the independent LU does not show its
correct status.
Defining the Network and Creating CNMCONxx
The CNMCONxx data set member of your VTAMLST contains a list of the major
nodes known to VTAM that are not included in the ATCCONxx (CNMS0003) data
set member of your VTAMLST. If all the major nodes that make up your network
are specified in the ATCCONxx, go to “Defining Resources by Names You
Choose.”
If all of your major nodes are not in ATCCONxx, define these major node names to
the status monitor. The resources in ATCCONxx are automatically started when
VTAM starts. If you want resources defined to the status monitor, but not started
at initialization, perform the following steps:
1. Create a member named for your major node that contains the VTAM
definitions for the node.
2. Define the name of the member by one of the following methods:
v Specify the name of the member in ATCCONxx on a status monitor
STATOPT statement. An asterisk (*) must occur in position 1 of this
statement, and STATOPT must start in position 16.
v Specify the name in a member called CNMCONxx in VTAMLST on VTAM
or STATOPT statements and ensure that CNMCON=xx is a part of the
parameter list in CNMNDEF that the preprocessor passes to CNMPP.
Note: CNMS0084 is included in the sample network as an example of a
CNMCONxx member.
After inserting STATOPT statements, run the status monitor preprocessor
CNMNDEF (CNMSJ007). Specify all the major node names that together define the
domain’s resources with an ATCCONxx list or a CNMCONxx list.
The CNMCONxx list must include the major and minor nodes that are not usually
part of the resources for a domain, but can be acquired. Any node that can be a
part of the domain, but is not yet acquired, is displayed as NEVACT on the status
monitor panels, if it is defined to the status monitor and its higher-level node is
not in RESET or RELSD status. All resources that are downstream of a resource in
RESET or RELSD status are shown as OTHER on the status monitor panels.
If you want information about...
Refer to...
The STATOPT statement
IBM Tivoli NetView for z/OS Administration
Reference
Defining Resources by Names You Choose
You can define a resource (such as a line or a physical unit) with a name of your
choice. To do this, insert a STATOPT statement directly after the VTAM or NCP
26
Installation: Configuring Additional Components
resource definition. An asterisk (*) must occur in position 1 of this statement, and
STATOPT must start in position 16. After inserting STATOPT statements, run the
status monitor preprocessor CNMNDEF (CNMSJ007).
The following examples show you some uses of STATOPT statements for your
production environment.
A01APPLS (CNMS0013): You can find the following STATOPT statement in
A01APPLS (CNMS0013):
&CNMDOMN.001 APPL AUTH=(NVPACE,SPO,ACQ,PASS),PRTCT=&CNMDOMN.,EAS=4,
MODTAB=AMODETAB,DLOGMOD=DSILGMOD
*
STATOPT='NETVIEW 001'
X
Where:
STATOPT
Specifies that the description NETVIEW 001 is assigned to APPL
CNM01001. This description is displayed on the DESCRIPT form of
the Status Detail panels.
You can change this STATOPT statement to the following statement:
&CNMDOMN.001 APPL AUTH=(NVPACE,SPO,ACQ,PASS),PRTCT=&CNMDOMN.,EAS=4,
MODTAB=AMODETAB,DLOGMOD=DSILGMOD
*
STATOPT=('NETVIEW 001',NOACTY)
X
Where:
NOACTY
Excludes the node from activity recording.
You can also change this STATOPT statement to the following statement:
&CNMDOMN.001 APPL AUTH=(NVPACE,SPO,ACQ,PASS),PRTCT=&CNMDOMN.,EAS=4,
MODTAB=AMODETAB,DLOGMOD=DSILGMOD
*
STATOPT=OMIT
X
Where:
OMIT Excludes this node and all the dependent lower nodes that follow from the
status monitor network definition.
A04A54C (CNMS0065): You can find the following example of the STATOPT
statement in A04A54C (CNMS0065):
A04F0020 LINE
*
ADDRESS=(020,FULL), ** LINK ADDRESS
SPEED=56000
** LINK SPEED
STATOPT=('LINE020',NOMONIT)
** X
**
Where:
‘LINE020’
Specifies that the description LINE020 is assigned to resource
A04F0020.
NOMONIT
Excludes the node from automatic reactivation.
You can find the following example of the STATOPT statement in A04A54C
(CNMS0065):
A04F1028 LINE
*
ADDRESS=(1028,FULL), ** LINK ADDRESS
SPEED=1843200
** LINK SPEED
STATOPT='LINK ADDR=1028'
** X
**
Where:
Chapter 2. Defining NetView Components
27
LINK ADDR=1028
Specifies that the description LINK ADDR=1028 is assigned to line
A04F1028. You can change this description to something more significant,
such as the name of the destination (for example, ATLANTA).
A01CDRM (CNMS0014): You can find the following example of the STATOPT
statement in A01CDRM (CNMS0014):
A01M
CDRM
*
CDRDYN=YES,
**
CDRSC=OPT,
**
ELEMENT=1,
**
ISTATUS=ACTIVE,
**
RECOVERY=YES,
**
SUBAREA=1,
**
VPACING=63
**
STATOPT='NETA CDRM'
AUTHORIZE DYNAMIC CD
AUTHORIZE DYNAMIC CD
DEFAULT
DEFAULT
DEFAULT
NETWORK UNIQUE SUBAREA ADDRESS
DEFAULT
X
X
X
X
X
X
Where:
NETA CDRM
Specifies that the description NETA CDRM is assigned to cross-domain
resource manager A01M. This node is included for automatic reactivation
and activity recording.
A01SNA (CNMS0073): You can find the following example of the STATOPT
statement in A01SNA (CNMS0073):
A01P7A0
PU
*
**
A01A7A02
A01A7A03
A01A7A04
A01A7A05
CUADDR=7A0,
**
DLOGMOD=M23278I,
**
MODETAB=AMODETAB,
**
USSTAB=AUSSTAB,
**
MAXBFRU=15,
**
PUTYPE=2,
**
VPACING=0
**
STATOPT='SNALOCALTERM'
LU
LU
LU
LU
LOCADDR=2
** LOGICAL UNIT
LOCADDR=3
** LOGICAL UNIT
LOCADDR=4
** LOGICAL UNIT
LOCADDR=5,
** LOGICAL UNIT
DLOGMOD=M3287SCS,
** DEFAULT LOG MODE ENTRY NAME
SSCPFM=USSSCS
** VTAM - SNA SCS PRINTER
STATOPT=('PRINTER',NOMONIT)
*
PHYSICAL UNIT ADDRESS
DEFAULT LOGON MODE ENTRY NAME
LOGON MODE TABLE NAME
USS DEFINITION TABLE NAME
VTAM BUFFERS TO RECEIVE DATA
TYPE 2 PHYSICAL UNIT
NO PACING FOR LU SESSIONS
**X
**X
**X
**X
**X
**X
**
**
**
**
**X
**X
**
Where:
SNALOCALTERM
Specifies that this STATOPT statement applies to PU A01P7A0 only.
PRINTER
Specifies that this STATOPT statement applies to LU A01A7A05 only.
NOMONIT
Specifies that NOMONIT excludes only the printer from automatic
reactivation.
Add STATOPT statements to define your resources.
28
If you want information about...
Refer to...
The STATOPT statement
IBM Tivoli NetView for z/OS Administration
Reference
Installation: Configuring Additional Components
Defining a Channel to the Status Monitor
You can assign names of a channel and its link station dynamically on the VARY
NET,ACT,ID=n command. However, the dynamic names you create are not known
to the status monitor unless you define them in VTAMLST. Refer to CTCA0102
(CNMS0038) and CTNA0104 (CNMS0081) for examples. In certain configurations,
you can define a channel-attachment major node that specifies the name to the
channel and the link station.
If you want information about...
Refer to...
Defining major nodes
The VTAM library
Defining a Host Physical Unit Name for Status Forwarding
Specify the HOSTPU parameter as a unique name within its network in ATCSTRxx
(CNMS0007). This enables the NetView system to assign a name to the physical
unit for the host.
If you want information about...
Refer to...
Assigning names to the physical unit for the
host
The VTAM library
Running the Status Monitor Preprocessor
Run the status monitor preprocessor CNMNDEF (CNMSJ007). After inserting the
STATOPT statements or after changing any VTAM or NCP definitions, run the
preprocessor.
Notes:
1. If you are using symbolics in the VTAM startup file, ATCSTRxx, or other
VTAMLST members, run the sample job CNMSJM12 against those members to
create a set of members with the symbolics resolved for use by the status
monitor preprocessor, CNMNDEF (CNMSJ007).
2. The status monitor preprocessor expects the VTAM and NCP definitions to be
working definitions. When defining an APPL major node, a VBUILD statement
is required by the NetView program even though this statement is not required
by VTAM. The status monitor preprocessor detects certain errors in the
definitions when these errors affect information required by the status monitor.
Various configurations require that you use the NCP/EP definition facility
(NDF) utility to modify and create new statements and keywords in the NCP
definitions. In these situations, provide the output from the NDF utility to the
status monitor preprocessor to ensure accuracy.
3. If you are using the NetView sample network, run the NCP generation
definitions provided by the NetView program through the NCP network
definition facility (NDF) utility before using these definitions in the sample
network. The NDF utility generates the correct NCP major node that is
referenced by VTAM. Run the NDF utility before running the status monitor
preprocessor CNMNDEF (CNMSJ007) or unpredictable results can occur.
The status monitor preprocessor processes the VTAM NETID keyword in various
types of major node definition files. This creates a list of network identifiers. This
list is added to the end of DSINDEF with a new record type. If you receive
message CNM048E BACKLEVEL DSINDEF - STATUS MONITOR MAIN TASK IS
TERMINATING, update your DSINDEF member by running the status monitor
preprocessor. The NetView program requires that a network identifier list be
included at the end of DSINDEF. This list is created automatically when you run
the status monitor preprocessor.
Chapter 2. Defining NetView Components
29
CNMNDEF (CNMSJ007) was copied to your system PROCLIB. The preprocessor is
a job in the sample network. However, you can change it to a system-started
procedure by following the instructions in the member.
Before you run the preprocessor, review the parameters that are passed to program
CNMPP. The syntax for the parameter statement is:
//
PARM='&START,LIST=&BOTH&LIST,CONFIG=&BOTH&CONFIG,CNMCON=&CNMCON'
Where:
CNMCON
Use the same value specified or implied for CNMCON when you
started VTAM. Include this parameter if you created a
CNMCONxx member for major nodes that are not included in
ATCCONxx. This is an optional parameter and no default value
exists. This value can be any two alphanumeric or national (@, #, $)
characters.
CONFIG
Use the value specified or implied for CONFIG when you started
VTAM. If you do not specify a CONFIG value in the PARM
statement, the preprocessor uses the CONFIG value specified in
ATCSTRxx. If you do not specify CONFIG in ATCSTRxx, the
default is 00, which points to configuration list ATCCON00
(CNMS0006). This value can be any two alphanumeric or national
(@, #, $) characters.
Notes:
1. The last two characters in ATCCONxx are set to the value of
CONFIG.
2. If you use the default of 00, make sure ATCCON00
(CNMS0006) is not empty.
HOSTSA
Use the same value specified or implied for HOSTSA when you
started VTAM. The default is 1.
HOSTSA can be any 1- to 5-character numeric value from 1 to the
value specified for RACSASUP in the VTAM constants module,
ISTRACON.
HOSTPU
Use the same value implied for the host PU name when you
started VTAM. If you do not specify HOSTPU in the parameter
statement, the preprocessor uses the HOSTPU value specified in
ATCSTRxx. If HOSTPU is not specified in ATCSTRxx, the NetView
program uses ISTPUS as the default. This is an optional parameter.
LIST
Use the value specified or implied for LIST when you started
VTAM (CNMS0010). This value can be any two alphanumeric or
national (@, #, $) characters.
Note: The last two characters in ATCSTRxx are set to the value of
LIST.
START
30
Values can be COLD or WARM. Use COLD to run the
preprocessor. WARM bypasses the preprocessor.
If you want information about...
Refer to...
RACSASUP
The VTAM library
Installation: Configuring Additional Components
Determining the Program Region Size for the Status Monitor
Preprocessor
The preprocessor requires a region size greater than or equal to:
(N x 80 bytes) / 1000 = S
Where:
N
Is the approximate number of nodes in the network.
S
Is the region size, rounded up to the next 1K bytes, with a minimum value
of 1K bytes.
Put this value in the JCL region parameter. If you code the region value as 0
(default), results are unpredictable.
Increase the space required in the DSIPARM library by 160 bytes per node. This
includes room for compressing the partitioned data set.
Starting the Status Monitor
You can start the status monitor using the STARTCNM STATMON command.
This command starts the following optional tasks:
v domain_nameVMT (for example, CNM01VMT)
v domain_nameBRW (for example, CNM01BRW)
Task domain_nameVMT uses DSICNM. DSICNM is a task initialization member in
the DSIPARM data set.
|
|
|
You can also start these tasks automatically during NetView initialization. To do
this, use the following task statement in the CNMSTUSR or CxxSTGEN member,
and update the INIT parameter. For information about changing CNMSTYLE
statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
TASK.&DOMAIN.VMT.INIT=Y
|
The Browse task is already set to INIT=Y in the CNMSTYLE member. Recycle the
NetView program for these changes to take effect.
Testing the Status Monitor
To go to the status monitor, enter:
STATMON
at the command line. You see a panel similar to Figure 2 on page 32.
Chapter 2. Defining NetView Components
31
STATMON.DSS
HOST: HOST01
.....3
....28
....31
....61
.....1
.....6
....24
.....2
.....1
....14
.....4
....86
.....2
.....4
.....2
....22
-----...291
NCP/CA/LAN/PK
LINES
PUS/CLUSTERS
LUS/TERMS
SWITCHED MAJ
SWITCHED PUS
SWITCHED LUS
LOCAL MAJ NDS
PUS
LUS/TERMS
APPL MAJ NDS
APPLICATIONS
CDRM MAJ NDS
CDRMS
CDRSC MAJ NDS
CDRSCS
------------TOTAL NODES
DOMAIN STATUS SUMMARY (REFRESH=ON)
09:54 A
*1* *2* *3* *4*
ACTIVE PENDING INACT
MONIT
NEVACT OTHER
...... ...... ...... ...... .....3 ......
...... ...... ...... ...... ....28 ......
...... ...... ...... ...... ....31 ......
...... ...... ...... ...... ....61 ......
...... ...... ...... ...... .....1 ......
...... ...... ...... ...... .....6 ......
...... ...... ...... ...... ....24 ......
.....1 ...... ...... ...... .....1 ......
...... ...... ...... ...... .....1 ......
.....6 ...... ...... ...... .....8 ......
.....3 ...... ...... ...... .....1 ......
....15 ...... ...... ...... ....48 ....23
.....1 ...... ...... ...... .....1 ......
.....1 ...... ...... ...... .....3 ......
.....1 ...... ...... ...... .....1 ......
...... ...... ...... ...... ....22 ......
------ ------ ------ ------ ------ -----....28 ...... ...... ...... ...240 ....23
CMD==>
TO SEE YOUR KEY SETTINGS, ENTER 'DISPFK'
Figure 2. Status Monitor Domain Status Summary Panel
You can browse the network log for any of the message alert settings, *1* through
*4*.
Position your cursor before message alert setting *1* and enter s.
You see a panel similar to Figure 3.
STATMON.BROWSE
ACTS NETWORK LOG FOR 2/1/01 (95136) COLS 017 094 09:56
HOST: HOST01
s *1* *2* *3* *4*
SCROLL ==> CSR
---2----+----3----+----4----+----5----+----6----+----7----+----8----+----9--CNM01
10:44:52
IST080I DSIKREM ACTIV
CNM01VPD CONCT
DSIROVS
CNM01
10:44:52
IST080I CNM01000 ACTIV
CNM01001 ACTIV
CNM01002
CNM01
10:44:52
IST080I CNM01003 ACTIV
CNM01004 ACT/S
CNM01005
CNM01
10:44:52
IST080I CNM01006 CONCT
CNM01007 CONCT
CNM01008
CNM01
10:44:52
IST080I CNM01009 CONCT
CNM01010 CONCT
CNM01011
CNM01
10:44:52
IST080I CNM01012 CONCT
CNM01013 CONCT
CNM01014
CNM01
10:44:52
IST080I CNM01015 CONCT
CNM01016 CONCT
CNM01017
CNM01
10:44:52
IST080I CNM01018 CONCT
CNM01019 CONCT
TAF01OPT
CNM01
10:44:52
IST080I TAF01O00 CONCT
TAF01O01 CONCT
TAF01O02
CNM01
10:44:52
IST080I TAF01O03 CONCT
TAF01O04 CONCT
TAF01F00
CNM01
10:44:52
IST080I TAF01F01 CONCT
TAF01F02 CONCT
TAF01F03
CNM01
10:44:52
IST080I TAF01F04 CONCT
TAF01F05 CONCT
TAF01F06
CNM01
10:44:52
IST080I TAF01F07 CONCT
TAF01F08 CONCT
TAF01F09
CNM01
10:44:52
IST080I TAF01F10 CONCT
TAF01F11 CONCT
TAF01F12
CNM01
10:44:52
IST080I TAF01F13 CONCT
TAF01F14 CONCT
TAF01F15
CNM01
10:44:52
IST080I TAF01F16 CONCT
TAF01F17 CONCT
TAF01F18
CNM01
10:44:52
IST080I TAF01F19 CONCT
CNM01
10:44:52
IST089I A01USER TYPE = APPL SEGMENT
, ACTIV
CMD==>
TO SEE YOUR KEY SETTINGS, ENTER 'DISPFK'
Figure 3. Status Monitor Network Log
On the top line of this panel, the abbreviation ACTS tells you that you are browsing
the active secondary network log.
Note: Low system activity can cause the data presented in the log display to lag a
few moments behind real events in the network.
32
Installation: Configuring Additional Components
Stopping the Status Monitor
You can stop the status monitor by using the STOPCNM STATMON command.
Defining the Hardware Monitor
The CNMSTYLE member defines the hardware monitor initialization values in
those statements that begin with the characters NPDA.
|
|
|
|
Review the default settings in the CNMSTYLE member and make any changes
necessary for your environment in the CNMSTUSR or CxxSTGEN member. For
information about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started. You can use the RESTYLE NPDA command to
enable changes without recycling the NetView program. The BNJDSERV task is
recycled. For more information, refer to the IBM Tivoli NetView for
z/OS Administration Reference.
Table 3. NPDA Statements
Function
CNMSTYLE Statement
Databases
NPDA.PDDNM
NPDA.SDDNM
NPDA.ALERTLOG
Data services tasks
NPDA.DSRBU
NPDA.DSRBO
NPDA.MACRF
Programmable network access (PNA) PU
downstream support
NPDA.PNA
Logging options
NPDA.REPORTS
NPDA.ALRTINFP.RECORD
PPI receiver name for alerts routed to the
event console
NPDA.TECROUTE
Storage for alerts (ALCACHE)
NPDA.ALCACHE
Hardware alerts panel data
NPDA.ALT_ALERT
NPDA.MDSIND
Wrap count
NPDA.W
Error-to-traffic (E/T) ration
NPDA.R
Thresholds for line quality and impulse hits
for leased lines connected to IBM LPDA-2
modems
NPDA.LQTHRESH
Rate at which events can be logged
NPDA.RATE
MSUs blocked by the RATE filter can pass to
the automation table
NPDA.AUTORATE
Basic Encoding Rules (BER) data
NPDA.PRELOAD_BER
Thresholding factor for messages generated
by incorrect alerts
NPDA.ERR_RATE
Alert forwarding protocol
NPDA.ALERTFWD
Recording filters
NPDA.PDFILTER
NPDA.IHTHRESH
Chapter 2. Defining NetView Components
33
Defining Passwords
The hardware monitor databases are defined using job CNMSJ004 using input
member CNMSI101.
To define security passwords for the hardware monitor databases:
1. Stop the hardware monitor.
2. Modify the definition statements in CNMSI101 that define the hardware
monitor databases, changing them to include the specification of VSAM cluster
passwords. Rerun job CNMSJ004 using these modified statements to delete and
redefine the hardware monitor databases.
3. Update the CNMSTPWD member in DSIPARM to include the passwords that
you specified when redefining the hardware monitor databases. The following
example shows the PWD statements that define the passwords for the
hardware monitor databases:
|
PWD.BNJDSERV.P = p_password
PWD.BNJDSERV.S = s_password
Where:
p_password
Is the 1- to 8-character password for the primary database.
s_password
Is the 1- to 8-character password for the secondary database.
4. Restart the hardware monitor.
Defining Additional Generic Alert Code Points
The hardware monitor allows for the definition of additional generic alert code
points and for additional resource types carried in the X'05' subvector.
The code point tables are installed in BNJPNL1. These tables are read during
NetView initialization and must have the following names:
v BNJ92TBL
v BNJ93TBL
v BNJ94TBL
v BNJ95TBL
v BNJ96TBL
v BNJ81TBL
v BNJ82TBL
v BNJ85TBL
v BNJ86TBL
While reading the tables during initialization, the NetView program allows syntax
errors in the code point entries and builds the tables if possible. Any major errors
(for example, a member not found or a control line that is not valid) result in an
empty table being built. This can cause undefined code point text seen by callers
and end users.
The user can change the code point tables before or after NetView initialization. If
the tables are changed after initialization, the user can issue the CPTBL command
to dynamically start the changes.
If you want information about...
Refer to...
Migrating and customizing generic alert code IBM Tivoli NetView for z/OS Customization
points
Guide
The CPTBL command
34
Installation: Configuring Additional Components
IBM Tivoli NetView for z/OS Command
Reference Volume 1 (A-N)
Changing the Colors of the Sample Network
The hardware monitor panels and color maps are defined by DD statements
BNJPNL1 and BNJPNL2 in CNMPROC (CNMSJ009). BNJPNL1 is searched for the
requested panel and BNJPNL2 is used for the related color map.
If you want information about...
Refer to...
How to change the color map to suit your
requirements
IBM Tivoli NetView for z/OS Customization
Guide
Starting the Hardware Monitor
You can start the hardware monitor using the STARTCNM NPDA command. This
command starts the following optional tasks:
v BNJDSERV
v BNJMNPDA
v DSICRTR
v DSI6DST
v domain_nameLUC
|
|
|
You can also start these tasks automatically during NetView initialization. To do
this, use the following task statements in the CNMSTUSR or CxxSTGEN member,
and update the INIT parameter. For information about changing CNMSTYLE
statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
TASK.BNJDSERV.INIT=Y
TASK.BNJMNPDA.INIT=Y
TASK.DSICRTR.INIT=Y
TASK.&DOMAIN.LUC.INIT=Y
|
|
The DSI6DST optional task is already set to INIT=Y in the CNMSTYLE member.
For these changes to the CNMSTYLE member to take effect, recycle the NetView
program.
Stopping the Hardware Monitor
You can stop the hardware monitor by using the STOPCNM NPDA command.
Defining the 4700 Support Facility
To define the 4700 support facility and its database, modify the following
statements:
v Consider the statements in BNJ36DST that define passwords.
v Consider the statements in the CNMSTYLE member that can be used to start the
4700 support facility
Defining Passwords
The 4700 support facility databases are defined using the CNMSJ004 job using
input member CNMSI401.
To define security passwords for the 4700 support facility:
1. Stop the 4700 support facility.
2. Modify the definition statements in CNMSI401 that define the 4700 support
facility databases, changing them to include the specification of VSAM cluster
passwords. Rerun the CNMSJ004 job using these modified statements to delete
and redefine the 4700 support facility databases.
Chapter 2. Defining NetView Components
35
3. Update the BNJ36DST member in DSIPARM to include the passwords that you
specified when redefining the 4700 support facility databases. The following
example shows the DSTINIT statements that define the DDNAMEs and
passwords for the 4700 support facility databases:
DSTINIT
DSTINIT
DSTINIT
DSTINIT
PDDNM=BNJ36PR
PPASS=password
SDDNM=BNJ36SE
SPASS=password
Where:
PPASS
Specifies the 1- to 8-character password for the primary
database.
SPASS
Specifies the 1- to 8-character password for the secondary
database.
4. Restart the 4700 support facility.
Starting the 4700 Support Facility
You can start the 4700 support facility with the STARTCNM TARA command. This
command starts the following optional tasks:
v BNJDSERV
v BNJDSE36
You can also start these tasks automatically during NetView initialization. To do
this, use the following task statements in the CNMSTUSR or CxxSTGEN member,
and update the INIT parameter. For information about changing CNMSTYLE
statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
|
|
|
TASK.BNJDSERV.INIT=Y
TASK.BNJDSE36.INIT=Y
For these changes to the CNMSTYLE member to take effect, you must recycle the
NetView program.
|
Stopping the 4700 Support Facility
You can stop the 4700 support facility by using the STOPCNM TARA command.
Defining the Session Monitor
The CNMSTYLE member defines the session monitor initialization values in the
statements that begin with the characters NLDM. For more information, see the IBM
Tivoli NetView for z/OS Administration Reference.
|
Table 4. NLDM Statements
Function
CNMSTYLE Statement
Databases
NLDM.PDDNM
NLDM.SDDNM
Data services task parameters
NLDM.DSRBO
NLDM.MACRF
Other domains
NLDM.AUTODOM
NLDM.AUTHORIZ.suffix
NLDM.CDRMDEF
36
Installation: Configuring Additional Components
Table 4. NLDM Statements (continued)
Function
Session awareness data collection
CNMSTYLE Statement
NLDM.SAW
NLDM.SAWNUM
NLDM.SAWSIZE
PIU trace parameters
NLDM.KEEPDISC
NLDM.KEEPPIU
NLDM.MAXEND
NLDM.PIUTNUM
NLDM.PIUTSIZE
RTM parameters
NLDM.RTM
NLDM.RTMDISP
NLDM.KEEPRTM
NLDM.PERFMEM
Trace started at initialization
NLDM.TRACEGW
NLDM.TRACELU
NLDM.TRACESC
Network parameters
NLDM.NETID
NLDM.LUCOUNT
Timers
NLDM.AMLUTDLY
NLDM.CDTIME
NLDM.DRDELAY
NLDM.FCTIME
NLDM.RETRY
External logging
NLDM.LOG
Session availability
NLDM.SESSTATS
Session wrapping
NLDM.KEEPSESS
ER data
NLDM.RTDASD
NLDM.ERCOUNT
Keep class definitions
NLDM.KEEPMEM
Display settings
NLDM.SESSMAX
Exception list
PEXLSTxx
Defining Passwords
The session monitor databases are defined using job CNMSJ004 using input
member CNMSI101.
To define security passwords for the session monitor databases:
1. Stop the session monitor.
2. Modify the definition statements in CNMSI101 that define the session monitor
databases, changing them to include the specification of VSAM cluster
passwords. Rerun job CNMSJ004 using these modified statements to delete and
redefine the session monitor databases.
Chapter 2. Defining NetView Components
37
3. Update the CNMSTPWD member in DSIPARM to include the passwords that
you specified when redefining the session monitor databases. The following
example shows the PWD statements that define the passwords for the session
monitor databases:
|
PWD.AAUTSKLP.P = p_password
PWD.AAUTSKLP.S = s_password
Where:
p_password
s_password
Is the 1- to 8-character password for the primary database.
Is the 1- to 8-character password for the secondary database.
4. Restart the session monitor.
Defining Sense Code Filtering
The most efficient method to filter sessions based on sense codes is to use the
VTAM VARY command.
You can also filter sessions using the session monitor. You can analyze a session
monitor VSAM data set and print the results using job CNMSJM10. The results
show how many times each unique sense code occurred. You can use this
information to decide which sense codes to filter.
The following sections explain how to:
v Decide which sense codes to filter.
v Add a sense code for filtering.
v Stop sense code filtering.
Deciding Which Sense Codes to Filter
To analyze the session monitor VSAM data set and filter sense codes:
1. Run job CNMSJM10.
The job generates a report that is sent to the printer. This report contains the
sense code (which includes the reason code) and frequency count for each
unique sense code. Figure 4 shows an example of such a report. In this report,
the sense codes and the reason codes are combined in the column labeled
SENSE CODE. The frequency counts are given in the column labeled TOTAL.
The report can contain a total of 200 sense code entries. If more than 200 sense
codes exist, the 200th sense code entry contains the frequency counts for the
remaining sense codes not displayed in the report.
SENSE CODE COUNTS:
ITEM#
---------1
2
3
---------TOTAL
SENSE CODE
---------00000000
087D0001
80200007
----------
TOTAL
---------3
8
1
---------12
PERCENT
----------25.0%
66.6%
8.3%
----------99.9%
Figure 4. Sense Code Report. The total in the percent column might not exactly equal 100%
because of mathematical rounding.
2. Analyze the report.
Look at the report to determine if any of the sense codes can be filtered.
Referring to Figure 4, suppose you decide to filter sense code 087D0001; go to
the next step.
38
Installation: Configuring Additional Components
3. Consult sample CNMS0055 which is shown in Figure 5.
*
* ENTRIES FOR
*
NSENSE
DC
*
*
SENSE01 DC
SLEN01
DC
*
*
SENSE02 DC
SLEN02
DC
DATA RECORDING SENSE CODE FILTERING
F'0'
NUMBER OF SENSE CODE ENTRIES IN TABLE
(BE SURE NUMBER IS NOT GREATER THAN 25)
XL4'00000000'
AL1(0)
SENSE CODE # 1 TO BE FILTERED
NUMBER OF SIGNIFICANT LEADING BYTES
FOR SENSE CODE # 1 COMPARISON
XL4'00000000'
AL1(0)
SENSE CODE # 2 TO BE FILTERED
NUMBER OF BYTES TO SENSE CODE # 2
Figure 5. Sample (as Supplied with the NetView Program)
If the sense code is in the sample, the sense code is being filtered (that is, it is
not recorded on the session monitor VSAM data set) and you do not have to
do anything. Otherwise, the sense code is NOT being filtered (it is recorded on
the session monitor VSAM data set).
Adding a Sense Code for Filtering
Continuing with the preceding example: The sense code you want to filter is not in
the sample. You need to add the sense code to the sample that you want to filter.
To add the sense code to the sample:
1. Modify DSICTMOD and reassemble using CNMS0055 to change filter status.
If the sample was the one shown in Figure 5:
a. Change NSENSE to the number of sense codes in the sample. Here, it is 1
because you want to filter only one sense code. This number cannot be
greater than 25 because the table holds only 25 sense code entries. See the
results of this change in Figure 6.
b. Change SENSE01 to the 2-byte sense code followed by the 2-byte reason
code. See the sense code report (in this example, Figure 4 on page 38) to get
the sense code and reason code of 087D0001. See the results of this change
in Figure 6 on page 40.
Note: To filter all sense codes with the same first 2 hexadecimal digits, fill
in the first 2 digits (1 byte) and fill the remaining 6 hexadecimal
digits (3 bytes) with zeros.
To filter all sense codes with the same first 4 hexadecimal digits, fill
in the first 4 digits (2 bytes) and fill the remaining 4 hexadecimal
digits (2 bytes) with zeros.
Change the number of significant bytes (SLEN01) to correspond with
your decision.
c. Change SLEN01 to the length of significant bytes. In this example, you want
to filter 087D0001, so you enter 4. See the results of this change in Figure 6
on page 40.
Chapter 2. Defining NetView Components
39
NSENSE DC F'1'
SENSE01 DC XL4'087D0001'
SLEN01 DC AL1(4)
(1 sense code in sample)
(Sense code/reason code)
(Use the entire 4 bytes)
SENSE02 DC XL4'00000000'
SLEN02 DC AL1(0)
Figure 6. Sample (with Sense Code 087D0001 Added)
2. Run CNMS0055 to reassemble DSICTMOD which initiates the filtering process.
Note: If the NetView system is currently active and values in DSICTMOD are
modified, restart the NetView program to use the new values.
In the example in Figure 6, sense code 087D0001 is now filtered.
3. Repeat the steps to filter additional sense codes. Remember to change NSENSE
by the number of sense codes in the sample.
Note: If you run sample CNMSJM10 again without clearing the VSAM data set
of the sense codes you just filtered, the sense codes remain in the VSAM
data set. However, the sense codes that were updated in DSICTMOD are
being filtered.
Stopping Sense Code Filtering
If you decide that you no longer want to filter a specific sense code, you can
change the sample by either:
v Changing the length of the sense code to 0; that is, AL1(0)
v Deleting the sense code entry from the table. (Deleting the sense code entries
that you no longer want to filter can help performance.)
If you change the length (SLEN01 in Figure 6) to 0, that sense code is skipped. Run
CNMS0055 to reassemble DSICTMOD to change filtering status.
Note: If the NetView system is currently active and the values in DSICTMOD are
modified, restart your NetView program to use the new values.
Whether you change the length of the sense code to 0 or delete it from the table
(DSICTMOD), maintain 25 two-line entries (place holders) in the table.
If you delete an entry (two lines), replace that entry in the table to maintain the
required 25 two-line entries in the table. To replace the entry:
1. Add the two-line entry beneath the last sense code in the table being filtered.
For example, assume you deleted the following from the table:
SENSE01 DC XL4 '08D70001'
SLEN01 DC AL1 (4)
Add the following as a place holder after the last sense code in the table being
filtered:
SENSE01 DC XL4 '00000000'
SLEN01 DC AL1 (0)
This procedure ensures that the filtered sense codes stay together at the top of
the table, and also maintains 25 entries in the table.
2. Change NSENSE to the number of filtered sense codes.
3. Run CNMS0055 to reassemble DSICTMOD to change filtering status.
40
Installation: Configuring Additional Components
Defining Session Awareness (SAW) Data
Decide how much session awareness (SAW) data and trace data you want to
collect and keep. You can keep data for all sessions, or just for specific sessions. For
each session for which SAW data is collected, decide the following items:
v The number of PIUs to keep
v Whether to keep session history data
For performance reasons, do SAW filtering at VTAM rather than at the NetView
program, although filtering at the NetView program is supported.
|
Filtering decides whether particular SAW data is collected at all. You can choose
what to do with the SAW data collected by the NetView program, as described
below:
v Review the defaults that are coded in the CNMSTYLE member.
v Review the KCLASS and MAPSESS statements supplied in AAUKEEP1.
v Make any necessary changes to the defaults.
If you want information about...
Refer to...
Setting up SAW data collection
IBM Tivoli NetView for z/OS Tuning Guide
Coding SAW in VTAM
The VTAM library
Coding KCLASS and MAPSESS Statements in the NetView
Program
|
|
>
>
A keep member is defined in the samples. You can alter it to define your keep
classes, or you can use the defined sample member by uncommenting the
NLDM.KEEPMEM statement in the CNMSTUSR or CxxSTGEN member. For
information about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started. To uncomment the KEEPMEM statement, remove
the asterisk from the following statement:
*NLDM.KEEPMEM=AAUKEEP1
This keep member contains two types of statements, KCLASS statements and
MAPSESS statements. The KCLASS statements define the restrictions to the
amount of data that is kept. You can have multiple KCLASS statements to define
different restrictions.
The KCLASS statements must occur at the beginning of the data set member.
KCLASS statements must precede all MAPSESS statements.
To change the keep member, create KCLASS statements to define your restrictions.
A sample KCLASS statement in AAUKEEP1 is:
* SAMPK2
*
*
*
*
KCLASS
SAW=YES,+
KEEPPIU=10,
DASD=YES,
KEEPSESS=10,
DGROUP=TSO
+
+
+
Where:
SAMPK2
Is the name of the keep class being defined.
SAW=YES
Specifies that session awareness data is kept. SAW=YES is the default.
Chapter 2. Defining NetView Components
41
KEEPPIU=10
Specifies the PIUs kept for each session in this keep class. This value can
be from 0 – 999, and the default is 7. In this example, 10 PIUs are kept.
DASD=YES
Specifies that sessions are always recorded to the session monitor VSAM
database.
KEEPSESS=10
Indicates the DASD session wrap count (0–999) for all sessions mapping
into this KCLASS. If the value is 0, session wrapping does not occur until
the count of sessions for this KCLASS exceeds 32767. Use the keyword
DASD=NO to prevent recording of sessions for this KCLASS. If KEEPSESS
is not coded, the global KEEPSESS value is used for sessions mapping into
this KCLASS. If the global wrap count is 0 in the CNMSTYLE member,
wrapping does not occur, regardless of the value of KEEPSESS. Also,
sessions are not recorded by DGROUPs.
|
DGROUP=TSO
Specifies the grouping characteristics of all the MAPSESS sessions mapping
to this KCLASS statement.
Note: To remove session data from the session monitor VSAM database, use the
PURGEDB command. Restrict the use of the PURGEDB command to
nonpeak times.
After you create your KCLASS statements, create MAPSESS statements. The
MAPSESS statements define the sessions to which a KCLASS statement apply.
In the samples, the first MAPSESS statement in AAUKEEP1 is:
MAP1
MAPSESS
KCLASS=SSCPSSCP,PRI=A??M,SEC=A??M
Where:
MAP1 Identifies the MAPSESS statement in any related error messages.
KCLASS
Specifies that any session that matches all the other MAPSESS operands is
to be assigned to keep class SSCPSSCP.
PRI=A??M
Specifies all primary session partner names that have a first character of A
and a fourth character of M.
SEC=A??M
Specifies all secondary session partner names that have a first character of
A and a fourth character of M.
In this example, any session where the primary session partner and the secondary
session partner have names with a first character of A and a fourth character of M
have SAW data stored as specified by KCLASS SSCPSSCP.
If you want information about...
Refer to...
The PURGEDB command
IBM Tivoli NetView for z/OS Command
Reference Volume 1 (A-N)
Discarding SAW Data
Code the information in the following sections in VTAM. VTAM includes a default
table, ISTMGC10 in VTAMLIB, where session awareness data (SAW) can be
42
Installation: Configuring Additional Components
filtered.
If you want information about...
Refer to...
Filtering SAW data from VTAM
The VTAM library
Specifying That SAW Data Is to Be Discarded: You can save storage by
discarding SAW data for selected SSCP-LU and LU-LU sessions. To do this, add
the following KCLASS statement to AAUKEEP1:
NOSAW
KCLASS
SAW=NO
You can then create MAPSESS statements to define those sessions for which you
want to discard the SAW data. An example of such a statement follows:
MAPD
MAPSESS
KCLASS=NOSAW,PRI=TSO*,SEC=B??B????
In this example, the SAW data is discarded for any session with:
v A KCLASS named NOSAW
v A primary end point name beginning with TSO
v A secondary end point name with B as both the first and the fourth characters
Starting the Session Monitor
You can start the session monitor using the STARTCNM NLDM command. This
command starts the following optional tasks:
v AAUTCNMI
v AAUTSKLP
v DSIAMLUT
v domain_nameLUC
v DSICRTR
You can also start these tasks automatically during NetView initialization. To do
this, use the following task statements in the CNMSTUSR or CxxSTGEN member,
and update the INIT parameter. For information about changing CNMSTYLE
statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
|
|
|
TASK.AAUTCNMI.INIT=Y
TASK.AAUTSKLP.INIT=Y
TASK.DSIAMLUT.INIT=Y
TASK.&DOMAIN.LUC.INIT=Y
TASK.DSICRTR.INIT=Y
For these changes to the CNMSTYLE member to take effect, recycle the NetView
program.
|
Stopping the Session Monitor
You can stop the session monitor by using the STOPCNM NLDM command.
Defining AON
The Automated Operations Network (AON) provides a way to provide automation
across multiple network protocols. AON intercepts alerts and messages that
indicate problems with network resources and attempts to recover failed resources.
Installation activities include the following activities:
v “Setting Up Base AON” on page 44
v “Setting Up AON/TCP Support” on page 52
Chapter 2. Defining NetView Components
43
v “Setting Up AON/SNA Support” on page 66
If you are running AON and System Automation for z/OS in the same NetView
address space, refer to “Enabling Workload Management to Manage the NetView
Program” on page 194. For more information about AON customization, refer to
IBM Tivoli NetView for z/OS User’s Guide: Automated Operations Network.
|
Setting Up Base AON
You can use Table 5 as you work through the AON installation tasks described in
this section.
Table 5. Base AON Installation Summary
Task
|
|
|
|
|
|
|
Job or Member
Name
Reference
Update the CNMSTUSR or CxxSTGEN DSIPARM
member to enable the AON tower and (CNMSTYLE)
subtowers, as necessary. For
information about changing
CNMSTYLE statements, see IBM Tivoli
NetView for z/OS Installation: Getting
Started.
v “Updating CNMSTYLE”
v IBM Tivoli NetView for
z/OS Installation: Getting
Started
Allocate VSAM clusters
CNMSAMP
(CNMSJ004)
“Allocating VSAM Clusters”
on page 45
If you are using an SAF product, add
gateway and automation operator
definitions and passwords
DSIPARM
(DSIOPF)
“Adding Gateway and
Automation Operator
Definitions and Passwords
(SAF only)” on page 46
Change the domain ID
CNMCLST
(EZLEISP1,
EZLEISP2)
“Changing the Domain ID”
on page 47
Update the NetView startup procedure CNMPROC
(CNMSJ009)
“Updating the NetView
Startup Procedure” on page
47
Update policy information.
DSIPARM
(CNMSTYLE)
“Updating CNMSTYLE”
v DSIPARM
(EZLCFG01)
v DSIPARM
(FKXCFG01)
v DSIPARM
(FKVCFG01)
v “Updating the Control File
Policy Definitions” on page
48
v IBM Tivoli NetView for
z/OS Automation Guide
|
|
Restrict access to AON commands and v CNMSAMP
menu selections.
(CNMSCAT2)
v “Restricting Access to AON
Commands and Menu
Selections” on page 51
v IBM Tivoli NetView for
z/OS Security Reference
Tune the REXX environment.
“Adding REXX Environment
Blocks” on page 52
DSIPARM
(CNMSTYLE)
Updating CNMSTYLE
To enable AON, update the AON TOWER statement in the CNMSTUSR or
CxxSTGEN member. Also update subtower statements in the CNMSTUSR or
|
|
44
Installation: Configuring Additional Components
|
|
|
CxxSTGEN member for additional functions that you are implementing. For
information about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started.
Subtower
Description
SNA
SNA automation (AON/SNA)
To also enable AON/SNA X.25 support, remove the asterisk (*)
from the following statement:
*TOWER.AON.SNA = X25
TCP
TCP/IP automation (AON/TCP)
To also enable Intrusion Detection Services (IDS) support, remove
the asterisk (*) from the following statement:
*TOWER.AON.TCP = IDS
AON uses policy definitions to provide automation of your network resources. The
NetView program loads the DSIPARM member EZLCFG01 control file during
initialization. This file contains values such as the notification operator IDs, the
automation operator IDs, threshold values for resources, monitoring values, and
recovery values. By default, the policy definitions are shipped enabled.
|
If you are migrating from a previous release of the NetView product, you might
want to change the policy definition member name. If so, locate the POLICY
statement in the CNMSTYLE member:
POLICY.AON = EZLCFG01
|
|
|
Use the POLICY.AON statement in the CNMSTUSR or CxxSTGEN member, and
change the name of the policy definition member. For information about changing
CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
If you want information about...
Refer to...
AON tower and subtower statements
IBM Tivoli NetView for z/OS Installation:
Getting Started
AON policy file
v “Updating the Control File Policy
Definitions” on page 48
v IBM Tivoli NetView for z/OS Automation
Guide
Allocating VSAM Clusters
Table 6 lists the VSAM databases that were allocated by sample job CNMSJ004
during base NetView installation.
Table 6. AON VSAM databases
VSAM database
Description
NETVIEW.CNM01.STATS
AON status database
NETVIEW.CNM01.LOGP
NETVIEW.CNM01.LOGS
AON log database
NETVIEW.CNM01.PASSWORD
AON password database for gateway
operator IDs and passwords
If changes are needed to these databases (for example, defining passwords or
allocating additional space), rerun CNMSJ004 to delete and define these databases.
Chapter 2. Defining NetView Components
45
Notes:
1. Place the VSAM database INDEX and DATA components on different devices
for better performance.
2. Because each AON component uses these VSAM clusters, you might need to
reallocate these clusters again if the initial space allocation is not large enough.
The AON VSAM clusters for the status database are allocated by default with 4
cylinders of hard disk drive. In very large networks, you might need to define
additional space.
3. The AON status database is allocated as REUSE so the DBMAINT facility can
properly perform database maintenance. The way the status databases are
allocated must match the value of the DBMAINT keyword in the ENVIRON
SETUP control file entry in EZLCFG01. By default, the ENVIRON SETUP
control file uses DBMAINT=REUSE.
If the values do not match, errors occur. For more information about the
ENVIRON SETUP control file entry, refer to the IBM Tivoli NetView for
z/OS Administration Reference.
Defining Passwords
The AON databases are defined using job CNMSJ004 using input member
EZLSI101.
To define security passwords for the AON databases:
1. Stop AON.
2. Modify the definition statements in EZLSI101 that define the AON databases,
changing them to include the specification of VSAM cluster passwords. Rerun
job CNMSJ004 using these modified statements to delete and redefine the AON
databases.
3. Update the CNMSTPWD member in the DSIPARM data set to include the
passwords that you specified when redefining the AON databases. The
following example shows the PWD statements that define the passwords for
the AON databases:
|
PWD.EZLSTAT.P = ps_password
PWD.EZLLOG.P = pl_password
PWD.EZLLOG.S = sl_password
Where:
ps_password
pl_password
sl_password
Is the 1- to 8-character password for the primary AON status
database.
Is the 1- to 8-character password for the primary AON log
database.
Is the 1- to 8-character password for the secondary AON log
database.
4. Restart AON.
Note: The use of a secondary AON status VSAM database is supported, but
not recommended.
Adding Gateway and Automation Operator Definitions and
Passwords (SAF only)
If you are using an SAF product such as RACF® for security, define all gateway
and automation operator IDs to that security product. The operator IDs are located
in DSIOPF include members EZLOPF, FKVOPF, and FKXOPF. Ensure that you
46
Installation: Configuring Additional Components
allocated a VSAM password data set (NETVIEW.CNM01.PASSWORD) that is used
to manage the RACF-required user IDs and passwords of the gateway operators
logging on to other NetView domains.
Changing the Domain ID
AON members are copied to the following NetView user data sets by sample job
CNMSJ003 during base NetView installation:
v NETVIEW.V5R4USER.CNM01.DSIPARM
v NETVIEW.V5R4USER.CNM01.CNMPNL1
To change the domain ID in AON members without having to edit the individual
members:
1. Copy the EZLEISP1 and EZLEISP2 members from the CNMCLST data set to a
data set in the SYSPROC concatenation of your TSO procedure. EZLEISP1 is
the program that changes the domain ID in the AON members. EZLEISP2 is a
macro called by EZLEISP1.
2. From TSO, enter the following command:
EZLEISP1 dataset olddomain newdomain
where:
dataset
The data sets that contain the members to be changed, which are typically,
the following data sets:
v NETVIEW.V5R4USER.CNM01.DSIPARM
v NETVIEW.V5R4USER.CNM01.CNMPNL1
For fully qualified data set names, include single quotation marks (')
around the data set name.
Note: Do not run EZLEISP1 against the SMP/E target or distribution
libraries.
olddomain
The domain ID that you want to change (the default domain ID is CNM01).
newdomain
The new domain ID.
For example, to change all occurrences of domain ID CNM01 to domain ID
CNM44 for the AON members in data set
NETVIEW.V5R4USER.CNM01.DSIPARM, enter:
EZLEISP1 'NETVIEW.V5R4USER.CNM01.DSIPARM' CNM01 CNM44
EZLEISP1 issues the following output messages:
time Processed dsn member, Modified.
time Processed dsn member, unchanged.
time Processed dsn member, ERROR RC = rc
Updating the NetView Startup Procedure
Make sure the following AON data sets are uncommented in CNMPROC
(CNMSJ009):
v Automation Status File data sets:
//* AON AUTOMATION STATUS FILE
//*
//*EZLSTAT DD
DSN=NETVIEW.CNM01.STATS,
//*
DISP=SHR,AMP='AMORG,BUFNI=10,BUFND=5'
v Automation Password data sets:
Chapter 2. Defining NetView Components
47
//* AON PASSWORD DATASET - FOR GATEWAY SESSION PASSWORD MANAGEMENT
//*
//*EZLPSWD DD
DSN=NETVIEW.CNM01.PASSWORD,
//*
DISP=SHR,AMP='AMORG,BUFNI=10,BUFND=5'
v Automation Log data sets:
//* AON AUTOMATION LOG DATASETS
//*
//*EZLLOGP DD
DSN=NETVIEW.CNM01.LOGP,
//*
DISP=SHR,AMP='AMORG,BUFNI=10,BUFND=5'
//*EZLLOGS DD
DSN=NETVIEW.CNM01.LOGS,
//*
DISP=SHR,AMP='AMORG,BUFNI=10,BUFND=5'
Notes:
1. The data set names on the DD statement in the NetView startup procedure also
are shown in the VSAM cluster definitions for the logs and status file. If you
changed the data set names, also make sure that the cluster definitions use the
new names.
2. If you changed the DD name, change all occurrences of the DD name in the
verify step of the NetView procedure. Also verify that the DD name in the
EZLLOGM and EZLSTSM members of the DSIPARM data set are the same as
the name you are using.
Updating the Control File Policy Definitions
The AON policy definitions are loaded when the NetView program is initialized.
AON provides minimum automation functions. Update the following policy
members in DSIPARM with additional information, such as TCP/IP for MVS stack
information:
v EZLCFG01 (AON base)
|
v FKXCFG01 (AON/TCP)
v FKVCFG01 (AON/SNA)
If you want information about...
Refer to...
Loading AON policy
“Updating CNMSTYLE” on page 44
AON policy definitions
IBM Tivoli NetView for z/OS Automation Guide
AON policy definition statements
IBM Tivoli NetView for z/OS Administration
Reference
Overview of AON Policy Definitions: The following table provides an overview
of the AON policy definitions, whether they are new or have changed for this
release, whether they are required, and which automation component they use.
Table 7. Control File Entries. An asterisk (*) next to the entry in the Component column indicates that the function no
longer requires AON; for more information, see Chapter 7, “Enabling IP Management,” on page 133.
Entry Description
|
Entry Name
New (N), Change
(C), or No
Change (NC)?
Required?
Component
Active monitoring
ACTMON
NC
No
Base*
Adjacent NetViews
ADJNETV
NC
No
Base
Automation operators
AUTOOPS
NC
Yes
Base
Automation of cross-domain
logons
CDLOG
NC
No
Base
Dynamic Display Facility
(DDF)
DDF
NC
Yes
Base
48
Installation: Configuring Additional Components
Table 7. Control File Entries (continued). An asterisk (*) next to the entry in the Component column indicates that
the function no longer requires AON; for more information, see Chapter 7, “Enabling IP Management,” on page 133.
Entry Description
Entry Name
New (N), Change
(C), or No
Change (NC)?
Required?
Component
Generic DDF
DDFGENERIC
NC
Yes
Base
Grouping DDF resources
DDFGROUP
NC
No
Base
Environment AIP status
ENVIRON AIP
NC
No
Base
DDF environment
ENVIRON DDF
NC
Yes
Base
Environment exit
ENVIRON EXIT
NC
No
Base
Environment RACF
ENVIRON RACF
NC
No
Base
Environment setup
ENVIRON SETUP
C
Yes
Base
Environment timeout
ENVIRON TIMEOUT
C
Yes
Base
Automation log
EZLTLOG
NC
Yes
Base
Notification forwarding for
focal point services
FORWARD FOCALPT
NC
No
Base
Application definition for
focal point services
FULLSESS
NC
No
Base
Notification forwarding
GATEWAY
NC
No
Base
Defining installed
components
INSTALLOPT
NC
No
Base
Large-scaling thresholds
LSTHRESH
NC
No
Base
Monitor intervals
MONIT
NC
Yes
Base
Monitor mode
MONITOR
NC
No
Base
Notification operators
NTFYOP
NC
Yes
Base
Recovery automation flag
RECOVERY
C
Yes
Base
Defining sessions to monitor
SESSION
NC
No
Base
Error thresholds
THRESHOLDS
NC
Yes
Base
Timer automation
TIMER
NC
No
Base
Include members
%INCLUDE
NC
No
Base
Notification policy
NOTIFY
NC
Yes
Base
Identify control points
CPCPSESS
NC
No
SNA
SNBU environments
ENVIRON SNBU
NC
No
SNA
NCP recovery
NCPRECOV
NC
No
SNA
Monitor sessions
SESSION
NC
No
SNA
Switched Network Backup
automation
SNBU
NC
No
SNA
SNBU default automation
parameters
SNBU DEFAULTS
NC
No
SNA
SNBU default PU parameters SNBU PU
NC
No
SNA
SNBU modem pool
definition
SNBUPOOL
NC
No
SNA
Subsystem for NetView
access
SUBSYSTEM
NC
No
SNA
Switch to backup line
TGSWITCH
NC
No
SNA
Chapter 2. Defining NetView Components
49
Table 7. Control File Entries (continued). An asterisk (*) next to the entry in the Component column indicates that
the function no longer requires AON; for more information, see Chapter 7, “Enabling IP Management,” on page 133.
Entry Description
Entry Name
New (N), Change
(C), or No
Change (NC)?
Required?
Component
X.25 switched virtual circuit
(SVC) definitions
X25MONIT
NC
No
SNA
Tivoli NetView for UNIX
service points
NV6000
NC
Yes
TCP
AON/TCP TSO Servers
TSOSERV
NC
No
TCP
Load CLIST into storage
RESIDENT
NC
No
Base
Critical AON/TCP Resource
Def
TCPIP
NC
No
TCP
|
TCP/IP for 390 Host Def
IPHOST
NC
No
TCP*
|
TCP/IP for 390 Interface Def
IPINFC
NC
No
TCP*
|
TCP/IP for 390 Router Def
IPROUTER
NC
No
TCP*
|
TCP/IP for 390 Socket Def
IPPORT
NC
No
TCP*
|
TCP/IP for 390 NameServer
Def
IPNAMESERV
NC
No
TCP*
|
|
TCP/IP for 390 Telnet Server
Def
IPTELNET
N
No
TCP*
|
TCP/IP for 390 TN3270
Server Def
IPTN3270
NC
No
TCP*
Before going to the next step, compare the contents of the AON control files with
your existing control files to determine what is required to merge these files. Merge
your customization into the new level of EZLCFG01, FKVCFG01, or FKXCFG01 in
the DSIPARM data set.
If you want information about...
Refer to...
Control file entries
IBM Tivoli NetView for z/OS Administration
Reference
Setting the Automation Log Switch: The AON automation log has automatic
switching capabilities. When the automation log is full, the EZLTLOG entry in the
control file specifies whether the automation log must be automatically switched.
You can also specify a job to run when the logs switch by modifying the EZLTLOG
entry in EZLCFG01 and uncommenting the JOB= parameter.
Figure 7 shows the EZLTLOG statements that are shipped with AON.
EZLTLOG
*
EZLTLOG
*
PRIMARY,AUTOFLIP=YES,
LIT='PRIMARY AUTOMATION LOG'
JOB=USER.PROCLIB(EZLSJ007)
SECONDARY,AUTOFLIP=YES,
LIT='SECONDARY AUTOMATION LOG'
JOB=USER.PROCLIB(EZLSJ009)
Figure 7. EZLTLOG statements
Where:
50
Installation: Configuring Additional Components
* CODE , *
* CODE , *
PRIMARY
Specifies the primary automation log.
SECONDARY
Specifies the secondary automation log.
AUTOFLIP
Specifies whether the log switches to the other log when the current log
fills up. The default as shipped is YES.
LIT
Specifies the text for the message that is used to notify operators of a log
switch.
JOB
Specifies the job to run when the logs switch.
To automatically switch to the secondary automation log, set the AUTOFLIP
keyword to YES on the primary EZLTLOG statement. To automatically switch back
to the primary automation log, set the AUTOFLIP keyword to YES on the secondary
EZLTLOG statement. To deactivate automation log functions, replace the two
EZLTLOG entries in Figure 7 on page 50 with the following single EZLTLOG entry:
EZLTLOG
NONE
Using a Sequential Data Set to Back Up Log Files: To use the a sequential data
set to automatically back up the automation logs, do these steps:
1. Run job EZLSJ005 in the NETVIEW.V5R4USER.INSTALL data set to allocate the
NETVIEW.LOGHIST data set used by the automation log backup. Update the
EZLSJ005 job to reflect the correct DASD type, data set name, and any other
information that is unique to your environment. The NETVIEW.LOGHIST data
set is a sequential data set to which AON appends log data when the primary
or secondary automation log file is full.
2. Copy the EZLSJ007 and EZLSJ009 jobs from the CNMSAMP data set to the
PROCLIB data set. These JCL jobs reproduce the automation log files into the
NETVIEW.LOGHIST data set before it is cleared. Review these jobs to make
sure that the cluster names and VSAM data set names are correct. Table 8
contains the names of the automation log, the name of the JCL job to run when
the log switches, and the name of the DSIPARM member that contains the
IDCAMS commands for the log.
Table 8. Information for sequential data set backup of log files
Automation Log
JCL Job
DSIPARM Member
NETVIEW.CNM01.LOGP
EZLSJ007
EZLSUP01
NETVIEW.CNM01.LOGS
EZLSJ009
EZLSUS01
3. Uncomment the entry with the JOB= keyword on the primary and secondary
EZLTLOG statements, making sure that the correct data set name is given for
the EZLSJ007 and EZLSJ009 sample jobs.
Notes:
a. Each line of an entry must end with a comma unless it is the last line of the
entry.
b. For automatic job submission, the subsystem interface (SSI) must be active.
Restricting Access to AON Commands and Menu Selections
You can use the NetView command authorization table or a system authorization
facility (SAF) product such as RACF to restrict access to commands and menu
selections.
Chapter 2. Defining NetView Components
51
AON displays the following message for unauthorized menu selections:
EZL215I OPTION opt NOT PROCESSED - ACCESS NOT AUTHORIZED
and the following message for unauthorized commands:
DSI213I ACCESS TO 'object' IS NOT AUTHORIZED
The initial NetView security settings are defined by the SECOPTS statements in the
CNMSTYLE member. Initially, you can use the default security settings and
restrictions for AON commands. As needed, identify commands or menu selections
to which you want to further restrict user access. For a list of AON commands,
keywords, and values that can be protected, refer to IBM Tivoli NetView for
z/OS Security Reference. Most menus (panels) have corresponding commands that
drive them. For example, a menu that begins with the characters FKXK have a
corresponding command named FKXE.
|
|
Adding REXX Environment Blocks
Consider tuning the REXX environment. You might need to allocate additional
blocks (300-400) depending on the number of subsystem and automation operators
that you define. You can use the DEFAULTS command or the
DEFAULTS.REXXSLMT statement in the CNMSTUSR or CxxSTGEN member to
increase the storage associated with a REXX environment. For information about
changing CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation:
Getting Started.
|
|
|
|
If more blocks are required than are available, the NetView program issues the
CNM416I REXX environment initialization error messages. If you receive this
message, review the number of blocks that you are allocating.
If you want information about...
Refer to...
REXX Environment
“Using Language Processor (REXX)
Environments in the NetView Environment”
on page 109
Setting Up AON/TCP Support
The NetView program provides the following TCP/IP functions. (TCP390
definitions are required only for remote TCP/IPs and to override discovered data.)
v Stack management
|
|
You can use SNMPView to manage the stacks. Both monitoring and
management functions support local and remote stacks.
v IP connection management
|
Using the 3270, Web browser, or NetView management console, you can manage
IP connections into your stacks. All connections are supported, including
TN3270, FTP, CICS, and SMTP. You can use operator filters to assist in reducing
the amount of data. You can view connection byte counts and take action (for
example, breaking the connection).
|
Note: This function is now provided in the base NetView program and no
longer requires AON/TCP.
v IP commands
|
|
Using the 3270, Web browser, or NetView management console, you can issue
various IP commands. AON/TCP on the 3270 provides IP command panels,
including the Ping, tracerte, and generic commands.
v IP server management
|
52
Installation: Configuring Additional Components
|
|
|
|
|
|
|
|
|
|
|
|
With the IP server management function, you can monitor and manage TSO and
UNIX servers from a 3270 panel. The panel displays the current status of the
servers and provides options to start and stop them.
v SNMP functions
Using 3270 panels, you can issue SNMP commands such as GET, SET, WALK,
and Remote Ping. You can also use the MIB groups function to define several
MIBs to be part of a group and use the NetView program to retrieve that group.
Sample MIB groups are provided.
Note: This function is now provided in the base NetView program and no
longer requires AON/TCP.
v IP resource manager
Using the IP resource manager, you can display any IP resource, including stacks
that are discovered by the discovery manager, and the current status of the
resource from 3270 panels. You can manage those resources by using options
that are provided on the panels.
Note: This function is now provided in the base NetView program and no
longer requires AON/TCP.
v Integration with CISCOWorks Blue Inter-network Status Monitor
Using 3270 panels, you can navigate to the CISCOWorks Blue Inter-network
Status Monitor, if it is installed.
v Proactive monitoring of IP resources
You can proactively monitor critical IP resources, including the following
resources:
– IP stacks
– Hosts
– Interfaces
– Routers
– TN3270 servers
For example, you can define a performance MIB to query within a router and
define a threshold. When you exceed that threshold, AON/TCP notifies you of
the problem.
|
|
Note: This function is now provided in the base NetView program and no
longer requires AON/TCP.
v IP connection monitoring and thresholding
You can monitor IP connections such as printer connections and apply policy
definitions to determine if they are unavailable. You can choose to notify an
operator or use automation to break the connection.
|
|
Note: This function is now provided in the base NetView program and no
longer requires AON/TCP.
v Intrusion Detection Services
You can use Intrusion Detection Services (IDS) support from the z/OS
Communications Server to delete the following IDS events and take actions:
– Scan detection
– Attack detection
– Traffic regulation for TCP connections
– UDP receive queues
Chapter 2. Defining NetView Components
53
Using the notification and inform policies, you can issue a message or generate
an alert, an IBM Tivoli Enterprise Console® event, e-mail, or report based on a
particular event type.
Note: This function is now provided in the base NetView program and no
longer requires AON/TCP.
v IP trace
Using 3270 panels or the Web browser, you can start and stop both component
and packet traces.
|
|
Note: This function is now provided in the base NetView program and no
longer requires AON/TCP.
|
|
You can use Table 9 as you work through the AON/TCP installation tasks
described in this section.
Table 9. AON/TCP Installation Summary
Task
|
|
|
|
|
|
|
54
Job or Member
Name
Reference
Update the CNMSTUSR or CxxSTGEN DSIPARM
member to enable the AON/TCP
(CNMSTYLE)
subtower. For information about
changing CNMSTYLE statements, see
IBM Tivoli NetView for
z/OS Installation: Getting Started.
v “Updating CNMSTYLE” on
page 44
v IBM Tivoli NetView for
z/OS Installation: Getting
Started
Enable AON/TCP IP390 automation
DSIPARM
(FKXTABLE)
“Enabling IP390 Automation”
on page 56
Configure a UNIX command server
v DSIPARM
(CNMSTYLE)
v CNMSAMP
(CNMSJUNX or
CNMSSUNX)
v DSIPARM
(CNMPOLCY)
v DSIPARM
(FKXCFG01)
“Configuring UNIX
Command Servers” on page
56
Configure a TSO command server
v DSIPARM
(CNMSTYLE)
v CNMSAMP
(CNMSJTSO or
CNMSSTSO)
v DSIPARM
(CNMPOLCY)
v DSIPARM
(FKXCFG01)
“Configuring TSO Command
Servers” on page 57
Configure NetView SNMP support
DSIPARM
(CNMSTYLE)
“Configuring NetView SNMP
Support” on page 58
Configure SNMP support
v DSIPARM
(CNMPOLCY)
“Configuring AON/TCP
SNMP Support” on page 59
Define at least one local MVS stack to
AON/TCP
DSIPARM
(CNMPOLCY)
“Defining Local TCP/IP
Stacks” on page 59
As needed, define stacks for remote
NetView domains
v DSIPARM
(CNMSTYLE)
v DSIPARM
(CNMPOLCY)
“Setting Up Cross-Domain
Communication” on page 60
Installation: Configuring Additional Components
Table 9. AON/TCP Installation Summary (continued)
Task
Job or Member
Name
Reference
Set up AON/TCP to monitor IP
resources
DSIPARM
(FKXCFG01)
“Setting Up for Proactive
Monitoring of IP Resources”
on page 62
If needed, update community names
DSIPARM
(CNMSCM and
CNMPOLCY)
“Resolving Community
Names (Optional)” on page
64
Enable TCP/IP connection
management
DSIPARM
(FKXCFG01)
“Managing TCP/IP
Connections” on page 64
Define the TCP/IP connection
monitoring policy
DSIPARM
(FKXCFG01)
“Defining TCP/IP Connection
Monitoring Policy” on page
65
Enable Intrusion Detection Services
DSIPARM
(CNMSTIDS)
“Enabling Intrusion Detection
Services” on page 65
Enable TCP/IP component trace
DSIPARM
(CNMSTYLE)
“Customizing TCP/IP
Tracing” on page 66
|
|
Defining AON/TCP Functions
Table 10 summarizes the required and optional tasks for implementing a particular
function.
Table 10. Customization by Function
|
|
Task
TCP/
IP
Stack
UNIX
Cmd
Srvr
TSO
Cmd
Srvr
Rmt
Stacks
Rmt
Rmt
Gtwys Srvr
Setup
Auto
tasks
Stack
management
RD
O
O
O
O
O
R/O
Ping command
RD
O
O
O
Tracerte
command
RD
O
O
O
O
Generic IP
commands
O
O
O
O
Manage IP
connections
RD
O
O
SNMP GET /
RD
SET/ and similar
tasks
SNMP MIB
groups
TN
3270
Srvr
SNMP SNMP
Setup Comm
Name1
R
O
R
O
O
R
O
RD
O
R
O
SNMP remote
Ping
RD
O
R
O
IP resource
manager
RD
O
O
R
O
IP trace support
RD
O
O
SNMP View
RD
O
R
O
Proactive
monitoring
RD
O
R
O
O
O
O
O
O
R/O
O
Monitoring
Method
O
Chapter 2. Defining NetView Components
55
Table 10. Customization by Function (continued)
Task
TCP/
IP
Stack
IP connection
monitoring and
thresholding
RD
Intrusion
detection
automation
RD
UNIX
Cmd
Srvr
TSO
Cmd
Srvr
Rmt
Stacks
Rmt
Rmt
Gtwys Srvr
Setup
Auto
tasks
TN
3270
Srvr
R/O
R
SNMP SNMP
Setup Comm
Name1
R
Monitoring
Method
O
R/O
Notes:
|
1. If you are using a community name, you must define it to the NetView program.
2. The abbreviations in the table have the following meanings:
v R: Required task
v RD: Required definition, coding by user is optional
v O: Optional task
v R/O: Required task, customization is optional
Enabling IP390 Automation
Review DSIPARM member FKXTABLE and verify that EZLOPT IP390,ENABLE=Y is
coded.
Disabling Tivoli NetView for AIX Support for TCP/IP
This EZLOPT statement performs the following actions:
v Prevents initialization of the AON/TCP tasks, automation operators, and global
variables
v Makes unavailable the NetView for AIX option on the operator interface panels
v Prevents AON/TCP from processing Tivoli NetView for UNIX alerts from the
automation table
To disable Tivoli NetView for AIX support for TCP/IP networks, edit the
FKXTABLE member and change the following statement:
EZLOPT NVAIX,ENABLE=Y
to
EZLOPT NVAIX,ENABLE=N
Note: Be sure, when you change FKXTABLE, that it does not contain any sequence
numbers. Sequence numbers in FKXTABLE can cause unpredictable results.
Defining Command Servers to AON/TCP
When you define stacks using the TCP390 policy definition, determine the
command servers that you need:
v UNIX command server (see “Configuring UNIX Command Servers”)
v TSO command server (see “Configuring TSO Command Servers” on page 57)
|
You can specify both UNIX and TSO command servers.
Configuring UNIX Command Servers: For information about the requirements
for the UNIX command server setup, see “Enabling the UNIX Command Server”
on page 208.
The following AON functions require a UNIX command server:
56
Installation: Configuring Additional Components
|
|
|
v Issuing UNIX commands (AON/TCP Option 2.4)
v AON/TCP NetView for AIX support
v Intrusion detection, if the syslog automation option or UNIX command types, or
both, are being used
To set up a UNIX command server:
1. Allocate an MVS initiator for the UNIX command server. If the command
server is to be run as a started task, an MVS initiator is not required. Refer to
the online command help for DEFAULTS and START for more information
about running the UNIX command server as a started task.
|
Note: The DEFAULTS.STRTSERV statement in the CNMSTYLE member
specifies how the command server must be run.
2. Customize CNMSSUNX in CNMSAMP to enable the UNIX command server to
run as a started task. This is the default.
Note: If necessary, you can customize CNMSJUNX in CNMSAMP to enable the
UNIX command server to run as a submitted job.
3. Create additional CNMSJxxx or CNMSSxxx jobs for multiple TCP/IP stacks.
4. Authorize all AON/TCP autotasks and any other operators to use the UNIX
command servers. The default autotask names are AUTTCP1 through
AUTTCP10 and are defined using the AUTOOPS policy definition in the
FKXCFG01 member. See “Defining TCP/IP Autotasks” on page 62 for task
names that need to be changed for your installation.
For the UNIX command server to start automatically for each stack during
initialization, specify UNIXSERV=YES on the TCP390 policy definition in
DSIPARM member CNMPOLCY. For more information, see “Defining Local
TCP/IP Stacks” on page 59.
Configuring TSO Command Servers: AON supports multiple TSO command
servers for improved performance. To set up multiple TSO command servers:
1. A TSO ID is required for each command server. TSO IDs for the command
servers must use the following naming convention:
v TSO IDs for TSO command servers must have the same name differentiated
by a trailing number.
v The trailing numbers are sequential and must start at 1.
v The base name must match the servname in the SERVER parameter of the
TCP390 statement.
v The count in the SERVER parameter is the highest numbered TSO command
server.
2. Allocate an MVS initiator for each TSO command server. If the command
servers are going to start as started tasks, MVS initiators are not required. Refer
to the online command help for DEFAULTS and START for more information
about starting the TSO command servers as started tasks.
|
Note: The DEFAULTS.STRTSERV statement in the CNMSTYLE member
specifies how the command server must be run.
3. Customize CNMSSTSO in CNMSAMP to enable the TSO command server to
run as a started task. This is the default.
Chapter 2. Defining NetView Components
57
Notes:
a. You can use the job name of the started task to qualify the RACF
started-class profile name. This provides additional granularity with RACF
protection than if a NetView user starts a TSO command server. You can
use the following command to display which operators started a TSO
command server:
MVS D A,L
b. If the additional RACF qualification is not needed, you can customize
CNMSJTSO in CNMSAMP to enable the TSO command server to run as a
submitted job.
4. Create additional CNMSJxxx or CNMSSxxx jobs for multiple TCP/IP stacks.
5. Define a TSOSERV policy definition for servname and reference CNMSJTSO (or
equivalent name).
6. Authorize all AON/TCP autotasks and any other operators to use the TSO
command servers. The default autotask names are AUTTCP1 through
AUTTCP10 and are defined using the AUTOOPS policy definition in the
FKXCFG01 member. See “Defining TCP/IP Autotasks” on page 62 for task
names that need to be changed for your installation.
For the TSO command server to automatically start for each stack during
initialization, update the following POLICY definitions:
v TCP390 (DSIPARM member CNMPOLCY)
v TSOSERV (DSIPARM member FKXCFG01)
For example, consider the following policy definitions:
TCP390
TSOSERV
NMPIPL10,
IPADDR=9.67.50.52,
COMMUNITYNAME=private,
DOMAIN=LOCAL,
UNIXSERV=YES,
SERVER=(NV2TS,3),
TCPNAME=TCPIP,
HOSTNAME=NMPIPL10.raleigh.ibm.com,
...
NV2TS,PROC=CNMSJTSO
These policy definitions set up three TSO command servers: NV2TS1, NV2TS2, and
NV2TS3. When started, AON/TCP uses CNMSJTSO as the procedure. These policy
definitions can also automatically start the UNIX command server
(UNIXSERV=YES). For more information, see “Defining Local TCP/IP Stacks” on
page 59.
Configuring NetView SNMP Support
|
|
Most AON/TCP functions are SNMP-based. See the comments in the CNMSTYLE
member in DSIPARM to configure the NetView SNMP command.
|
|
Note: This function is now provided in the base NetView program and no longer
requires AON/TCP.
|
|
|
To make updates, use the following statements in the CNMSTUSR or CxxSTGEN
member, and make any necessary modifications. For information about changing
CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
COMMON.CNMSNMP.MIBS = all
COMMON.CNMSNMP.MIBPATH = /etc/netview/mibs:/usr/lpp/netview/v5r4/mibs
COMMON.CNMSNMP.timeout = 1
COMMON.CNMSNMP.retries = 5
58
Installation: Configuring Additional Components
For security considerations, see the IBM Tivoli NetView for z/OS Security Reference.
Configuring AON/TCP SNMP Support
|
|
AON/TCP uses SNMP requests for many functions. Several policy definitions can
affect those requests.
Table 11 contains policy definitions for SNMP requests that are defined in
EZLCFG01 and CNMPOLCY. If AON/TCP SNMP requests experience frequent
timeout errors, you can adjust the values.
Table 11. Control File Entries
Control File Entry
Parameter
Value to Adjust
TCP390 DEFAULTS
SNMPRETRY=2
Specifies the number of times the SNMP
request is to be retried, for example:
SNMP GET ... -r 2 ...
SNMPTO=3
Specifies the number of seconds that SNMP
waits for a response, for example:
SNMP GET ... -t 3 ...
NONREP=0
Specifies the number of non-repeating
variables for a BULK request, for example:
SNMP GETBULK ... -B 0 xx ...
This parameter is sets up default values for
the NVSNMP GETBULK operator request.
MAXREP=10
Specifies the maximum number of repetitions
of repeating variables for a BULK request, for
example:
SNMP GETBULK ... -B xx 10 ...
This parameter is sets up default values for
the NVSNMP BULKWALK operator request.
ENVIRON TIMEOUT SNMP=29
Specifies the time in seconds for AON/TCP to
wait for a response to an SNMP request
within a PIPE (for example, a SOCKET
command).
Defining Local TCP/IP Stacks
|
|
At a minimum, define at least one local MVS stack to AON/TCP. If you do not
define this, it is defined automatically by the NetView discovery manager.
Use the TCP390 policy definition in DSIPARM member CNMPOLCY to define a
local TCP/IP stack. The entire stack definition, or portions of it, are optional.
NetView dynamically determines information about your stack, such as its IP
address, host name, and TCP process name. If you want to run with default values
for all functions (such as Intrusion Detection Automation Services), you do not
need to define a TCP390 statement for your stack. You need to define your stack if
you want to override the default settings. The following example defines a local
stack named NMPIPL10:
TCP390
NMPIPL10,
IPADDR=9.67.50.52,
COMMUNITYNAME=private,
DOMAIN=LOCAL,
UNIXSERV=YES,
Chapter 2. Defining NetView Components
59
SERVER=(NV2TS,3),
TCPNAME=TCPIP,
HOSTNAME=NMPIPL10.raleigh.ibm.com,
...
Notes:
1. The stack NMPIPL10.raleigh.ibm.com is known as NMPIPL10.
2. SNMP requests (for example, stack monitoring processes) uses a community
name of private. The default community name is public.
3. The NetView domain managing this stack is the LOCAL domain. This value
can be set to the local domain ID. The local domain is the same domain where
this policy definition resides.
4. This policy defines both the UNIX command server and three TSO command
servers. For more information, see “Defining Command Servers to AON/TCP”
on page 56.
5. You can specify either the IPADDR (recommended) or HOSTNAME parameter.
If you do not specify the IPADDR, AON/TCP dynamically determines the IP
address of the stack based on the HOSTNAME parameter. This takes additional
processor cycles.
6. For security, if you specify COMMUNITYNAME, restrict access to the member
containing your policy definitions.
7. TCPNAME defines the TCP/IP start procedure name. AON/TCP supports
system symbolics. You can use TCPNAME=&CNMTCPN.
|
|
|
|
|
For more information about the TCP390 policy definition, refer to IBM Tivoli
NetView for z/OS Administration Reference.
Setting Up Cross-Domain Communication
|
Some AON/TCP functions (for example connection management, SNMP functions,
monitoring functions, IP tracing functions, and commands) support communication
with remote NetView domains.
|
The discovery manager discovers all local stacks on a given system. Code TCP390
definitions for stacks on systems that are outside of your sysplex.
For example, to set up for cross-domain communication from NMPIPL10 (domain
NTV70) to NMPIPL27 (domain NTV9D):
v In NTV70, define TCP/IP stacks on the remote domain. For example, to define a
stack named NMPIPL27 in NetView domain NTV9D, use the following
definition:
TCP390
NMPIPL27,
IPADDR=9.67.50.41,
DOMAIN=NTV9D,
UNIXSERV=YES,
TCPNAME=TCPIP,
HOSTNAME=NMPIPL27.raleigh.ibm.com,
...
v In NTV9D, define the policy for the local stack:
TCP390
NMPIPL27,
IPADDR=9.67.50.41,
DOMAIN=LOCAL,
UNIXSERV=YES,
TCPNAME=TCPIP,
HOSTNAME=NMPIPL27.raleigh.ibm.com,
...
For more information about TCP390 policy definitions, refer to IBM Tivoli NetView
for z/OS Administration Reference.
60
Installation: Configuring Additional Components
For cross-domain communication, set up a remote gateway session. For example,
to establish a remote gateway from NMPIPL10 (domain NTV70) to NMPIPL27
(domain NTV9D):
v On NTV70, define a gateway operator autotask using the AUTOOPS policy
definition. For example, on NTV70:
AUTOOPS
GATOPER,ID=GATNTV70
defines GATNTV70 as the gateway autotask in domain NTV70.
v To automatically start remote gateway sessions when the GATNTV70 autotask is
logged on, define CDLOG entries for your GATOPER autotask. Make sure that
each operator in the target domain is defined in DSIOPF.
For example, define a CDLOG policy definition in NTV70 for each target
domain. To connect to domain NTV9D, use the following CDLOG entry:
CDLOG
GATNTV70.NTV9D,
SESSTYPE=RMT,
INIT=YES,
TARGOP=RMTNTV70,
DESC='RMT GATEWAY TO NTV9D'
In this case, when operator GATNTV70 logs on, a RMTCMD session is
automatically started to NTV9D as RMTNTV70.
For more information about CDLOG, refer to IBM Tivoli NetView for
z/OS Administration Reference.
|
|
|
For each remote NetView domain and each TCP/IP stack that you plan to use, add
the following statement to the CNMSTUSR or CxxSTGEN member. For information
about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started.
auxInitCmd.IP = EXCMD AUTO1,FKXERINI
spname
servername
count
proc
where:
spname
The name of your local TCP/IP stack.
servername
The name of the TSO or UNIX command server on the MVS host.
Servername is the root TSO command server ID when defining multiple
TSO command servers. When defining a UNIX command server, set
servername to YES. If AON IP390 is installed and this is a TSO command
server, then servername must match the root TSO command server ID
defined for the TCP/IP stack :
TCP390 .... SERVER=(servername,count)
count
If defining TSO command servers, the count parameter is the number of
TSO command servers that are defined for this TCP/IP stack. The
minimum is 1 and the maximum is 5. If defining a UNIX command server,
set count to UNIX.
If AON IP390 is installed and this is a TSO command server, the count
parameter must match the count defined for the TCP/IP stack :
TCP390 .... SERVER=(servername,count)
proc
The name of the job to start the command servers.
The default job for TSO command servers is CNMSJTSO for submitted jobs
and CNMSSTSO for started tasks. If AON IP390 is installed, proc must
Chapter 2. Defining NetView Components
61
match the job found on the TSOSERV definition for the corresponding
servername. For example, TSOSERV servername,PROC=proc
The default job for the UNIX command server is CNMSJUNX for
submitted jobs and CNMSSUNX for a started task.
FKXERINI initializes:
v The TSO or UNIX command server used by AON IP390 functions in the remote
domain
v Global variables that are used by AON IP390 functions
FKXERINI is run during NetView startup in the local and remote domains.
FKXERINI must run in all domains against each local stack.
As needed, define TSO or UNIX command servers.
Defining TCP/IP Autotasks
AON/TCP provides policy definitions for 10 NetView autotasks that can be used
for TCP/IP automation and management. Review the following statement in
DSIPARM member FKXCFG01:
AUTOOPS
TCPOPER,ID=(AUTTCP,10)
This defines AUTTCP1 through AUTTCP10 as the autotasks used by AON/TCP.
Modify this statement as necessary for your installation (for example, change
AUTTCP to AONTCP). If you change the autotask IDs, also make changes to
DSIOPF to define your task IDs.
For more information about the AUTOOPS statement, refer to IBM Tivoli NetView
for z/OS Administration Reference.
Setting Up for Proactive Monitoring of IP Resources
You can use AON/TCP to proactively monitor your critical IP resources based on
policy definitions. You can use the following monitoring methods:
v “Pinging a Resource” on page 63
v “MIB Polling” on page 63
v “MIB Thresholding” on page 63
Note: This function is now provided in the base NetView program and no longer
requires AON/TCP.
|
|
When AON/TCP proactive monitoring detects a failure:
v AON/TCP uses the NOTIFY policy to determine the type of notification to be
sent.
v AON/TCP schedules a recovery monitoring timer. This timer is scheduled as
specified on the MONIT policy definitions. The timer checks the resource status
and optionally sends a notification that the resource is still down.
Table 12 shows the IP resource types you can monitor and the required policy
definitions.
Table 12. Control File Entries
62
Resource
Policy Definition
Host
IPHOST
Stack
TCP390
Router
IPROUTER
Installation: Configuring Additional Components
Table 12. Control File Entries (continued)
|
Resource
Policy Definition
Interface
IPINFC
Socket
IPPORT
Server
IPNAMESERV
Telnet server
IPTELNET
TN3270 server
IPTN3270
IP connection
IPCONN
As shipped, IPCONN definitions are commented out.
For more information about policy definitions, refer to IBM Tivoli NetView for
z/OS Administration Reference.
Pinging a Resource: To perform a ping of a resource, code FORMAT=PING on its
policy definition. If the ping response works, the resource status is NORMAL. If
not, the resource status is DOWN.
MIB Polling: MIB polling uses SNMP to poll the interface table (ifTable) for the
defined resource. The administration status is compared to the operational status.
If one or more interfaces are expected to be up and are not, the resource is marked
as degraded. Degraded does not mean that the resource is down.
To enable MIB polling, code FORMAT=SNMP, as shown in the following example:
IPHOST HOST01,SP=NMPIPL10,
OPTION=IP390
ACTMON=ALLHOSTS,
FORMAT=SNMP,
STATUS=(NORMAL,DEGR*),
HOSTNAME=host01.raleigh.ibm.com
The ACTMON=ALLHOSTS statement refers to the following statement that contains a
common definition for monitoring all the IP hosts:
ACTMON ALLHOSTS,OPTION=IP390,INTVL=00:30,STATUS=NORMAL,
FORMAT=PING
Using this definition, HOST01 is monitored every 30 minutes using a ping. The
expected status is NORMAL (resource is active).
Additionally, you can add the following status parameter so that a status of
degraded is not treated as a resource failure: STATUS=(NORMAL,DEGR*).
MIB Thresholding: MIB thresholding uses SNMP to query MIBs defined in the
policy definition for the resource. You can define the MIB, its threshold value, and
the threshold operator (greater than, less than, equal). When the proactive
monitoring timer pops, AON/TCP retrieves the MIB values and compares them to
the policy definition for the resource. For example, to add a MIB threshold to the
HOST01 resource and use the ipRoutingDiscards.0 MIB, code the following
statements:
IPHOST HOST01,SP=NMPIPL10,
OPTION=IP390
ACTMON=ALLHOSTS,
FORMAT=SNMP,
STATUS=(NORMAL,DEGR*,THRESH*),
MIBVAR=(ipRoutingDiscards.0,GE,3),
HOSTNAME=host01.raleigh.ibm.com
Chapter 2. Defining NetView Components
63
In this example, if the MIB value is greater than or equal to 3, the resource status is
set to THRESH. Notice also that THRESH is an acceptable status and therefore is
not treated as a resource failure.
Resolving Community Names (Optional)
Note: This function is now provided in the base NetView program and no longer
requires AON/TCP.
When monitoring resources using SNMP, the NetView program might need access
to the community name for a resource. NetView SNMP reads MIB data from
community-name protected resources using DSIPARM member CNMSCM.
|
|
To use CNMSCM for community name resolution, add an entry line for each host
name to be resolved to a community name and then save the file. For more
information, see the IBM Tivoli NetView for z/OS Administration Reference. To
prevent unauthorized viewing or modification of CNMSCM, see the IBM Tivoli
NetView for z/OS Security Reference.
For information about defining community names to TCP/IP, see the z/OS
Communications Server IP Configuration Reference.
Note: This definition is for resources that are not TCP/IP stacks.
|
Managing TCP/IP Connections
|
|
|
TCP/IP connections can be established for any socket and can be established using
a TN3270 server. You can manage these connections from the 3270 interface, the
NetView management console, or the Web browser.
|
|
|
Note: This function is now provided in the base NetView program and no longer
requires AON/TCP. However, AON/TCP is still required for the IBM 2210,
the IBM 2216, and the CISCO CIP.
To enable connection management, see Table 13.
Table 13. Connection Management
Connection
See
To a local TCP/IP stack
“Defining Local TCP/IP Stacks” on page 59
|
Set up your local stack definition with SNMP capability.
From a TN3270 server
“Setting Up for Proactive Monitoring of IP Resources” on
page 62 (TN3270 servers)
Because most stacks have numerous connections, consider limiting the amount of
data that your operator must view. To do this, you can use one of the following
methods:
v Code SESSTAT=NO on the IPPORT definition. All connection data for that port
is ignored. Code this for ports that you do not want to manage.
For example, if you do not want to manage connections with the NetView Web
server interface task:
IPPORT DSIWBTSK,SP=NMPNET10,
PORT=80,
PROTOCOL=TCP,
TCPNAME=NVPROCN,
STATUS=NORMAL,
64
Installation: Configuring Additional Components
FORMAT=PORT,
SESSTAT=NO,
DESC="NetView Web Browser Socket"
v Use a session filter. You can define filters for each operator to restrict the data
based on IP address, local MVS port, LU, and application. For more information
about session filters, refer to the IBM Tivoli NetView for z/OS User’s Guide:
Automated Operations Network.
v For the Web browser, adjust the MAXCONN parameter. In the Web browser, you
can limit the number of connections shown based on the value of the
MAXCONN parameter on the TP390 DEFAULTS definition. Sample FKXCFG01
sets the limit to 1000. This limit applies to all connection types.
Defining TCP/IP Connection Monitoring Policy
You can monitor IP connections such as printer connections and apply policy
definitions to determine if they are stopped. You can choose to notify an operator
or use automation to break the connection.
|
|
Note: This function is now provided in the base NetView program and no longer
requires AON/TCP.
To do this, customize the sample policy definitions in FKXCFG01:
*AUTOOPS CONNOPER,ID=AUTCMON
*ACTMON IPCONN,INTVL=00:01:00
*NOTIFY IPCONN,ALERT=NO,MSG=YES,DDF=NO,INFORM=NO
*IPCONN TCPIP*,
Enabling Intrusion Detection Services
|
|
|
|
To enable Intrusion Detection Services (IDS), review the IDS statements in the
CNMSTIDS member and update AON policy definitions in the CNMSTUSR or
CxxSTGEN member (see Table 14). For information about changing CNMSTYLE
statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
|
|
Note: This function is now provided in the base NetView program and no longer
requires AON/TCP.
Table 14. IDS Support
Policy Definition
Update
TCP390
On the TCP390 stack policy definition, define your local
TCP/IP stack and specify IDSAUTO=Y and optionally
specify the IDSINTVL parameter.
NOTIFY
By default, the NOTIFY IDSAUTO policy is set up to
issue alerts and messages for IDS events. You can
optionally update this policy to enable IDS events to be
forwarded to the Tivoli Enterprise Console. For example:
NOTIFY
NTFYOP
IDSAUTO,
ALERT=TEC,
MSG=YES,
DDF=NO
Use the NTFYOP policy definition to define which
NetView operators receive IDS messages (class=64). For
example:
NTFYOP
OPER1,
OPER='IDS-AUTO-SVCS',
CLASS=(64),HELDMSG=(I)
Chapter 2. Defining NetView Components
65
Table 14. IDS Support (continued)
INFORM
Update the Inform policy for e-mail notifications (reports
and responses to commands). For example:
GROUP IDSOPERS,LIST=OPER1,OPER2,OPER3;
INFORM OPER1;
CONTACT CONNECTION=EMAIL,
INTERFACE=EZLESMTP,
[email protected],
NAME=C. PERSON;
INFORM OPER2,...
INFORM OPER3,...
For more information, refer to sample EZLINSMP.
For more information about the policy definitions, refer to IBM Tivoli NetView for
z/OS Administration Reference.
Customizing TCP/IP Tracing
Output writers can be used to store trace data for later analysis. You can customize
the default output writer names for component or packet trace in the CNMSTYLE
member. Review the following statements for your environment and make changes
as appropriate in the CNMSTUSR or CxxSTGEN member. For information about
changing CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation:
Getting Started.
v Source JCL definitions for component and packet trace:
|
|
|
|
|
|
|
COMMON.EZLTCPcTRACEwriter = CTTCP
COMMON.EZLTCPpTRACEwriter = PKTCP
// Component trace writer name
// Packet trace writer name
The Open Systems Adapter (OSA) trace does not have a default writer. You can
use the packet trace writer for OSA packet trace data.
|
|
v Time interval to wait for a response:
COMMON.EZLIPTraceJCLWait
= 2
// ... for source JCL error response
|
|
|
For more information about IP tracing, see IBM Tivoli NetView for z/OS IP
Management. For information about the IPTRACE command, which enables trace
control through a panel interface, see the NetView online help.
|
|
Note: This function is now provided in the base NetView program and no longer
requires AON/TCP.
Setting Up AON/SNA Support
You can use Table 15 as you work through the AON/SNA installation tasks
described in this section.
Table 15. AON/SNA Installation Summary
Task
|
|
|
|
|
|
66
Job or Member
Name
Reference
Update the CNMSTUSR or CxxSTGEN DSIPARM
member to enable the AON/SNA
(CNMSTYLE)
subtower. For information about
changing CNMSTYLE statements, see
IBM Tivoli NetView for
z/OS Installation: Getting Started.
v “Updating CNMSTYLE” on
page 44
v IBM Tivoli NetView for
z/OS Installation: Getting
Started
Remove recovery support from the
status monitor for resources that
AON/SNA monitors
“Updating the Status
Monitor” on page 67
Installation: Configuring Additional Components
DSIPARM
(DSICNM)
Table 15. AON/SNA Installation Summary (continued)
Task
Job or Member
Name
Reference
Define the subsystem interface address PARMLIB
space
(MPFLST)
“Defining the Subsystem
Interface Address Space”
If you do not need subarea resource
automation support, disable subarea
processing
DSIPARM
(FKVTABLE)
“Setting Up AON/SNA
Subarea Support” on page 68
Enable Advanced Peer-to-Peer
Networking support
v DSIPARM
(FKVTABLE)
v DSIPARM
(FKVCFG01)
“Enabling Advanced
Peer-to-Peer Networking
Monitoring Support” on page
68
Enable X.25 support
v DSIPARM
(FKVTABLE)
v DSIPARM
(DSICRTTD)
v DSIPARM
(FKVCFG01)
“Implementing X.25
Monitoring” on page 69
Updating the Status Monitor
For AON/SNA support, update the STATMON statements in DSICNM in the
following way:
1. Comment out the following two statements from the command list name table:
C
C
MONON
MONOFF
2. Comment out the O MONIT statement. Unless this statement is removed or
commented out, AON/SNA cannot function correctly.
3. MONIT must be turned off for every resource to ensure that AON/SNA
performs recovery for these resources.
4. You can still use the STATMON entry to reflect the current status of network
resources in an automated environment.
Defining the Subsystem Interface Address Space
To define subsystem interface address space:
1. If you are not running with extended consoles, define a subsystem interface
(SSI) address space for the NetView program. This enables AON to submit jobs
for log file maintenance and to support the NetView Access Services
component of the AON helpdesk facility.
2. Check the message processing facility list (MPFLST) in PARMLIB and make
sure that all EZL messages can be sent to and from the NetView program. If
your NOENTRY or DEFAULT entries in the MPF list are SUP(NO) AUTO(NO),
specify the following entry for AON:
EZL*,SUP(NO),AUTO(YES)
3. If you have IBM NetView Access Services (NVAS) and use the AON SNA Help
Desk to help manage those sessions, make sure that all EMS messages can pass
to and from the NetView program. If you use NVAS and your NOENTRY or
DEFAULT entries in the MPF list are SUP(NO) AUTO(NO), specify the
following entry for AON:
EMS*,SUP(NO),AUTO(YES)
Chapter 2. Defining NetView Components
67
Notes:
1. If you are not using a console automation package, specify all other messages
with AUTO(NO) to prevent them from going to the NetView program and to
improve performance.
2. If you are using a console automation package, you must code an automation
table entry at the top of the table to discard extraneous messages coming from
the SSI to AON. For example, if the MPFLST entry for console automation is:
IEF*,SUP(NO),AUTO(YES)
The corresponding automation table entry for AON is:
IF MSGID='IEF'.
THEN DISPLAY(N) NETLOG(N);
Setting Up AON/SNA Subarea Support
AON/SNA subarea automation is automatically enabled.
If you do not need subarea resource automation support, disable subarea
processing. This also prevents AON/SNA SNBU from operating on PU
thresholding exceptions. However, AON/SNA SNBU automation can still occur
from alerts.
To disable subarea support, follow these procedures:
1. Edit the FKVTABLE member and locate the following statement:
EZLOPT SA,ENABLE=Y
Note: Be sure when you change FKVTABLE that it does not contain any
sequence numbers. Sequence numbers in FKVTABLE can cause
unpredictable results.
2. Change ENABLE=Y to ENABLE=N.
These procedures cause the following actions:
v Prevents subarea initialization
v Disables the subarea menu by make it unavailable from the operator
interface
v Prevents message processing of subarea related automation in automation
table
If you want SNA subarea support to recover your NCPs, add an NCPRECOV
statement for each channel-attached NCP for this host. For more information, refer
to the IBM Tivoli NetView for z/OS Administration Reference.
Enabling Advanced Peer-to-Peer Networking Monitoring Support
To set up AON/SNA Advanced Peer-to-Peer Networking, perform the following
steps:
1. Enable AON/SNA Advanced Peer-to-Peer Networking by changing the
following statement in the FKVTABLE member:
EZLOPT APPN,ENABLE=N
to:
EZLOPT APPN,ENABLE=Y
Note: Be sure when you change FKVTABLE that it does not contain any
sequence numbers. Sequence numbers in FKVTABLE can cause
unpredictable results.
68
Installation: Configuring Additional Components
2. Decide which control points you want to monitor. If you are not sure which
control points you want to monitor, you might want to enable AON/SNA
Advanced Peer-to-Peer Networking and not define any resources. After you
enable AON/SNA Advanced Peer-to-Peer Networking, you can use the
operator panel portion of AON/SNA Advanced Peer-to-Peer Networking to
look at AON/SNA Advanced Peer-to-Peer Networking resources and issue
Advanced Peer-to-Peer Networking-related VTAM commands. When you
decide which resources you want to actively monitor, add an entry for each
control point to FKVCFG01 as shown in the following example:
ACTMON USIBMTA.TA1CP208,RESTYPE=CP,
OPTION=APPN,INTVL=01:00
This example shows that you can use network-qualified names.
3. Decide which CP-CP sessions you want to actively monitor. These sessions are
defined using two statements:
ACTMON GARTH,RESTYPE=CPCPSESS,OPTION=APPN
CPCPSESS GARTH,CP1=USIBMNR.NR51W001.GARTH,CP2=USIBMTA.TA01
The ACTMON control file entry defines the resource and resource types you
want to monitor. An alias is used for the CPCPSESS control file entry. The
interval for active monitoring can be specified on each ACTMON statement. If
it is not specified, the value specified on the ACTMON APPN entry is used.
In the preceding example, GARTH is an alias name used only by AON/SNA to
refer to the session. These alias names need to be unique within AON/SNA.
The CPCPSESS statement defines the actual session between the two control
points specified by the CP1 and CP2 entries. You can use network-qualified
names.
Implementing X.25 Monitoring
This section explains how to install and implement AON/SNA X.25 support. These
instructions assume AON/SNA is already installed.
To set up X.25 support:
1. Enable X.25 support by changing the following statement in the FKVTABLE
member. Change:
EZLOPT X25,ENABLE=N
to:
EZLOPT X25,ENABLE=Y
Note: Be sure when you change FKVTABLE that it does not contain any
sequence numbers. Sequence numbers in FKVTABLE can cause
unpredictable results.
2. Edit the DSICRTTD member of your DSIPARM data set and uncomment the
following statement:
DSTINIT XITCI=FKVXITAN
Note: AON ships with the FKVXITAN XITCI exit already in CNMLINK. To
modify the exit, use the FKVPITAN sample that is found in CNMSAMP.
3. Define X25MONIT entries in your control file for switched virtual circuit
monitoring. The default control file member for AON/SNA is FKVCFG01.
Completing AON Tailoring
At this point, you can initialize AON and complete the installation verification
procedure. You might need to make additional modifications to the control file
Chapter 2. Defining NetView Components
69
entries to enable additional AON functions, and to maximize the performance of
functions such as RECOVERY, THRESHOLDS, and MONIT.
Testing AON Automation
The following tests verify that AON automation is working properly.
Note: You must be logged on as a notification operator (your user ID must be
defined as a NTFYOP) to perform this test.
Testing the Enhanced Automation
1. Log on to the NetView program.
2. Enter EZLEATST
Sample result:
NetView V5-NM
Tivoli NetView
CNM01 OPER1 01/10/02 11:16:22
* CNM01
EZLEATST
W CNM01
DSI039I MSG FROM AUTO1
: AONCMD TEST SUCCESSFUL
M CNM01
DSI039I MSG FROM OPER1
: AON MSG TEST SUCCESSFUL
M CNM01
DSI039I MSG FROM OPER1
: TESTING WAIT TIMEOUT FUNCTION (WAITING
29 SECONDS)
C AON01
EZL001I REQUEST WAIT WAS SUCCESSFUL FOR TIMEOUT
The EZLEATST routine calls a command list that tests NetView functions
requested by the AON &WAIT, &WAIT TIMEOUT, MSG, and EXCMD
functions. Verify that these functions completed successfully. If any errors are
detected, the test issues a message and stops.
Verifying AON Tasks
To verify that the AON tasks are active:
1. Enter LIST STATUS=TASKS
2. Verify that the following AON tasks are active:
v EZLTCFG
v EZLTSTS
v EZLTLOG
v EZLTDDF
v AONBASE
v AONMSG1
v AONMSG2
v AUTALRT
v AUTTRAP
Notes:
a. AUTTRAP is active only if the AON/TCP tower is enabled.
b. There might be additional tasks depending on how much customization has
been done and which automation components are active.
3. Enter REGISTER QUERY=MS.
4. Verify that the following applications are registered:
AONALERT
Required for sending MSUs to the hardware monitor
EZLMSAPL
If you are using the AON workstation interface
Verifying AON Panels
Complete the following test to verify that the AON panels display correctly.
1. Enter AON.
Sample result:
70
Installation: Configuring Additional Components
EZLK0000
AON: Operator Commands Main Menu
CNM01
Select an option
_ 0.
1.
2.
3.
Tutorial
AON Base Functions
SNA Automation
TCP/IP Automation
2. Enter 1.
Sample result:
EZLK0100
AON: Base Functions
CNM01
Select an option
_ 0.
1.
2.
3.
4.
5.
6.
7.
8.
9.
Tutorial
Help Desk
AutoView
DDF
Automation Settings
Cross Domain Functions
Timer
Task and Log Maintenance
Support Functions
Display the Inform Log
3. Enter 4.
Sample result:
EZLK4000
AON: Automation Settings
CNM01
Select an option
_ 1.
2.
3.
4.
5.
Automation
Notification Operators
Thresholds
Monitor Intervals
Active Monitoring
4. Press F2.
Sample result:
EZLK0000
AON: Operator Commands Main Menu
CNM01
Select an option
_ 0.
1.
2.
3.
Tutorial
AON Base Functions
SNA Automation
TCP/IP Automation
Testing AON Commands
You must be a notify operator (NTFYOP) to use many of these commands.
To test the AON commands, follow these steps:
1. Enter SETNTFY operid to verify that the EZL919I message is received, indicating
the operation was successful.
2. Log on to the new notify operator ID.
Chapter 2. Defining NetView Components
71
3. Enter DISNTFY to verify that you receive the automation status of the notify
operators.
4. Enter DISAUTO to verify that the default automation settings are loaded from the
control file.
5. Enter AONTRACE ENTRY ON DOMAIN to verify that the EZL241W message is
received, indicating that your request was unsuccessful.
6. Enter NLOG to verify that no startup messages are displayed on the panel.
7. Enter POLICY REQ=STATUS to verify that the control file is loaded.
8. Enter POLICY REQ=GET ENTRY=NTFYOP to list the notify operators specified in the
AON control file.
9. Enter DSPCFG NTFYOP to verify that similar information is displayed.
Testing AON/SNA
This section provides installation verification procedures for the following
functions:
v AON/SNA VTAM subarea automation
v AON/SNA Advanced Peer-to-Peer Networking monitoring
v AON/SNA X.25 monitoring
Testing AON/SNA VTAM Subarea Automation
This section shows you how to set up a test for SNA recovery.
Testing SNA Resource Recovery: To perform resource recovery for SNA:
v AON and AON/SNA installed and customized
v An available test PU
v Your ID set up as a notification operator (NTFYOP) with a message class of 20
v AON/SNA SNBU disabled during the test
v DDF customized for your environment
v Enter DSPCFG MONIT command to display monitor intervals
v Monit intervals for PUs must be those shipped in the sample control file
You can cause a failure on the PU by:
v Turning off the controller
v Unplugging from the patch panel
The following message is displayed from the command facility while running the
test. During the test, TA1P523A is the name of your PU. The message is:
EZL506I PU TA1P523A ON CNM01 INACTIVE - RECOVERY MONITORING
HAS BEEN INITIATED
If you do not receive this message, check the netlog. If you find the message in the
netlog, you might not be set up as a notification operator.
Checking DDF: To check DDF, perform the following steps:
1. Enter: DDF
2. Move the cursor to SNA.
3. Press F8 to page down.
Your PU is displayed in pink.
4. Move the cursor to PU and press F8.
5. Move the cursor to your PU name and press F2 to show the details associated
with the PU.
AON/SNA displays the Detail Status Display panel.
72
Installation: Configuring Additional Components
Sample result:
---- DETAIL STATUS DISPLAY ---1 OF
COMPONENT: TA1P523A
SYSTEM
COLOR
: PINK
PRIORITY :
DATE
: 10/19/00
TIME
: 09:53:06
NODE
: CNM01
REPORTER : AONMSG2
2
: CNM01
270
DUPLICATE COUNT:
1 '*EZL506I PU TA1P523A ON CNM01 INACTIVE - RECOVERY MONITORING HAS
BEEN INITIATED'
Checking Timers: To check your timers:
1. Enter TIMER on the command line.
2. Press Enter. The NetView program displays the Timer Management panel.
When you do this test, notice the timer for your PU.
Sample result:
EZLK6000
Target:
TIMER MANAGEMENT
CNM01 NETOP1
10/19/00 8:28:41
1 TO
5 OF
Total Selected Timers:
Total Purged Timers:
Target Network ID:
Filter criteria:
Type one action code. then press enter.
1|A=Add 2|C=Change 3|P=Purge 4=Add CHRON timer
Timer ID Scheduled
Type Interval Task
_ EZL00002 10/19/00 10:29:27 AFTER
AONNET2
EZLECATV TA1P523A PU 2 10/19/00 09:51
Save
5
5
0
Catchup
3. Press F3 to return to the command facility.
After a few minutes, the following message is displayed:
EZL507I REMINDER: PU TA1P523A ON CNM01 HAS BEEN UNRECOVERABLE
FOR 4 MINS.
4. Resolve the hardware error, which causes the following message to display:
Sample result:
EZL504I PU TA1P523A IS AVAILABLE (REPORTED BY CNM01)
If you check DDF, AON/SNA has deleted your PU name from the CNM01
Network Status - Physical Units panel.
Sample result:
FKVPNLP
PAGE 1 OF 1
CNM01 NETWORK STATUS - PHYSICAL UNITS
PU
Checking the NLOG: To display the NetView automation log:
1. Enter NLOG on the command line.
Sample result:
Chapter 2. Defining NetView Components
73
LOG BROWSE - CNM01
COMMAND ===>
*EZL509I
*EZL506I
*EZL507I
*EZL504I
ACTS 10/19/00 (96040)---- MSG --------- COLUMNS 062 139
SCROLL ===> PAGE
PU TA1P523A IS UNAVAILABLE (REPORTED BY CNM01)
PU TA1P523A ON CNM01 INACTIVE - RECOVERY MONITORING HAS BEEN INITIATE
REMINDER: PU TA1P523A ON CNM01 HAS BEEN UNRECOVERABLE FOR 4 MINS.
PU TA1P523A IS AVAILABLE (REPORTED BY CNM01)
Testing Thresholding: To test the thresholding, make the PU fail enough times to
trip the critical threshold.
Note: These testing examples use the shipped defaults. If you use values other
than the shipped defaults, the information shown on your panels can vary
from those shown here.
To trip the critical threshold:
1. Set your critical threshold to 2 errors in 10 minutes for PUs using the
SETTHRES command.
2. Cause the PU to fail.
When you trip the critical threshold, you see the following messages:
EZL509I PU TA1P523A IS UNAVAILABLE (REPORTED BY CNM01)
EZL501I RECOVERY FOR PU TA1P523A ON CNM01 HALTED - 2 ERRORS
SINCE 09:51 ON 01/09/97 - CRITICAL ERROR THRESHOLD EXCEEDED
Go back to DDF before resolving the hardware error that occurred. To go to DDF:
1. Enter DDF on the command line.
2. Follow the steps in “Checking DDF” on page 72 to display the Detail Status
Display panel for your PU name.
Sample result:
---- DETAIL STATUS DISPLAY ---1 OF
COMPONENT: TA1P523A
SYSTEM
COLOR
: RED
PRIORITY :
DATE
: 10/19/00
TIME
: 11:54:34
NODE
: CNM01
REPORTER : AONMSG
2
: CNM01
175
DUPLICATE COUNT:
1 'EZL501I RECOVERY FOR PU TA1P523A ON CNM01 HALTED - 2 ERRORS SINCE
11:49 ON 10/19/00 - CRITICAL ERROR THRESHOLD EXCEEDED'
3. Resolve the hardware error that occurred during the test.
Testing NCP Recovery: You can bypass this section if you are not using
AON/SNA to perform NCP recovery. To perform this test, you must have an NCP
available that can be forced to fail. In addition, the NCPRECOV control file entry
for your NCP must be coded in the following way:
NCPRECOV ncpname,HOST=domainid,DUMP=(N,N),RELOAD=(Y,N),
LINKSTA=link_sta_name,DUMPSTA=link_sta_name
This specifies
74
Installation: Configuring Additional Components
v No for dump
v Yes to reload for noncritical responses
Note: Specify no (N) for the AUTODMP and AUTOIPL parameters in the PCCU
macro for the NCP you are using to test.
Causing a Failure on the NCP: You can cause a failure on the NCP by taking one of
the following actions:
v Enter initial program load (IPL) from the Moss console.
v The initial machine load (IML) from the front panel.
If you cause the NCP to fail, you receive messages similar to:
EZL509I LINKSTA 0F31-S IS UNAVAILABLE (REPORTED BY CNM01)
EZL506I NCP TA1N500 ON CNM01 INACTIVE - RECOVERY MONITORING
HAS BEEN INITIATED
EZL509I LINKSTA 0F31-S IS UNAVAILABLE (REPORTED BY CNM01)
EZL509I NCP TA1N500 IS UNAVAILABLE (REPORTED BY CNM01)
EZL509I LINKSTA 0F31-S IS UNAVAILABLE (REPORTED BY CNM01)
FKV532I REPLY OF -NO- WAS ISSUED BY AUTOMATION FOR TA1N500
FROM CNM01: NON-CRITICAL DUMP REPLY FROM RECOVERY HOST
FKV535I REPLY OF -YES- WAS ISSUED BY AUTOMATION FOR TA1N500 FROM
CNM01: NON-CRITICAL RELOAD REPLY FROM RECOVERY HOST
FKV556I LOAD OF TA1N500 BY OPERATOR STARTED
FKV544I RELOAD WAS SUCCESSFUL FOR TA1N500 AND IS AVAILABLE
EZL504I LINKSTA 0F31-S IS AVAILABLE (REPORTED BY CNM01)
EZL504I LINKSTA 0F31-S IS AVAILABLE (REPORTED BY CNM01)
EZL504I NCP TA1N500 IS AVAILABLE (REPORTED BY CNMM01)
Note: The messages are displayed after the dumps and loads are completed.
Therefore, a significant amount of time might pass before the messages are
displayed.
Checking the NLOG: To display the NetView automation log, enter NLOG on the
command line.
Sample result:
LOG BROWSE - CNM01
COMMAND ===>
ACTS 10/19/00 (96040)---- MSG --------- COLUMNS 062 139
SCROLL ===> PAGE
EZL509I LINKSTA 0F31-S IS UNAVAILABLE (REPORTED BY CNM01)
*EZL506I NCP TA1N500 ON CNM01 INACTIVE - RECOVERY MONITORING HAS BEEN INITIATE
EZL509I LINKSTA 0F31-S IS UNAVAILABLE (REPORTED BY CNM01)
EZL509I NCP TA1N500 IS UNAVAILABLE (REPORTED BY CNM01)
EZL502I RECOVERY FOR NCP TA1N500 ON CNM01 CONTINUING - 1 ERRORS SINCE 12:57 ON
FKV532I REPLY OF -NO- WAS ISSUED BY AUTOMATION FOR TA1N500 FROM CNM01 : NON-CR
FKV532I REPLY OF -NO- WAS ISSUED BY AUTOMATION FOR TA1N500 FROM CNM01 : NON-CR
FKV535I REPLY OF -YES- WAS ISSUED BY AUTOMATION FOR TA1N500 FROM CNM01 : NON-C
*EZL509I LINKSTA 0F31-S IS UNAVAILABLE (REPORTED BY CNM01)
FKV556I LOAD OF TA1N500 BY OPERATOR STARTED
FKV544I RELOAD WAS SUCCESSFUL FOR TA1N500 AND IS AVAILABLE
EZL504I LINKSTA 0F31-S IS AVAILABLE (REPORTED BY CNM01)
*EZL504I LINKSTA 0F31-S IS AVAILABLE (REPORTED BY CNM01)
*EZL504I NCP TA1N500 IS AVAILABLE (REPORTED BY CNM01)
Testing AON/SNA Advanced Peer-to-Peer Networking Monitoring
To test the AON/SNA Advanced Peer-to-Peer Networking, test checkpoint
commands and the control point display.
Checkpoint Commands: To test the checkpoint commands:
1. From the command facility, enter AON.
Chapter 2. Defining NetView Components
75
2.
3.
4.
5.
Select 2 for SNA.
Select 6 for Advanced Peer-to-Peer Networking.
Select 1 for Issue checkpoint commands.
Select 3 for Checkpoint both databases.
Sample result:
FKVK5100
Operator Command Interface: VTAM Commands
CNM01
Output of: F NET,CHKPT,TYPE=ALL
IST097I
IST1123I
IST1123I
MODIFY ACCEPTED
MODIFY CHKPT TO DATASET TRSDB
MODIFY CHKPT TO DATASET DSDB2
Command ===>
F1=Help
F2=Main Menu
F7=Backward F8=Forward
WAS SUCCESSFUL
WAS SUCCESSFUL
F3=Return
F6=Roll
F12=Cancel
Control Point Display Command: To test the control point display:
1. From the command facility, enter AON.
2. Select 2 for SNA.
3. Select 6 for Advanced Peer-to-Peer Networking.
4. Select 2 for Display control points.
Sample result:
FKVKA200
SNA Automation: APPN CP Display
Type an action code. Then press Enter.
1=Details 2=Delete Topology 3=Delete Directory
5=Timers
6=AutoView
Control Point
Node Type
_ ISTADJCP
ADJCP MAJOR NODE
_ USIBMTA.TA1PT106
EN
_ TA1CP213
*NA*
_ TA1CP214
*NA*
_ USIBMTA1.OPER1
EN
_ USIBMTA.NTC0PUN6
*NA*
_ USIBMTA.TA1CP210
EN
_ APPN.TA1PT209
EN
_ USIBMXXX.YYY00000
EN
_ USIBMTA.TA1PT107
EN
_ USIBMTA.TA1PT220
EN
_ USIBMTA.TA1CP207
NN
_ USIBMTA.TA1PT203
EN
_ TA1CP208
*NA*
Command ===>
F1=Help
F2=Main Menu
F7=Backward F8=Forward
76
Installation: Configuring Additional Components
F3=Return
CNM01
More:
4=Active Monitoring
F5=Refresh
+
F6=Roll
F12=Cancel
Testing AON/SNA X.25 Monitoring
This section explains how to test X.25 automation for AON/SNA. X.25 automation
includes the LUDRPOOL and X25MONIT functions.
Testing the LUDRPOOL Function: You can bypass this section if you do not use
X.25 with dynamic reconfiguration. To perform this test, you must have dynamic
reconfiguration LUs defined in your NCP.
To begin the test:
1. Enter LUDRPOOL.
2. AON/SNA displays the SNA Automation: X25 LUDRPOOL panel.
Sample result:
FKVKX200
SNA Automation: X25 LUDRPOOL
CNM01
NCP name : ________
Monitor
: 2
(1=Yes
2=No)
Interval : 10
Threshold: 000
Command ===>
F1=Help
F2=Main Menu
F3=Return
F6=Roll
F12=Cancel
3. Enter the name of your NCP in the NCP name field. AON/SNA updates the
SNA Automation: X25 LUDRPOOL panel.
Sample result:
FKVKX200
SNA Automation: X25 LUDRPOOL
CNM01
NCP name : TA1N500_
Monitor
: 2
(1=Yes
2=No)
Interval : 10
Threshold: 000
FKV651I LUDRPOOL FOR NCP TA1N500 = 104
Command ===>
F1=Help
F2=Main Menu F3=Return
F6=Roll
F12=Cancel
4. Change the value in the Monitor field from 2 to 1 to turn on Monitoring, and
press Enter. AON/SNA updates the SNA Automation: X25 LUDRPOOL panel.
Sample result:
Chapter 2. Defining NetView Components
77
FKVKX200
SNA Automation: X25 LUDRPOOL
CNM01
NCP name : TA1N500_
Monitor
: 1
(1=Yes
2=No)
Interval : 10
Threshold: 000
EZL001I REQUEST LUDRSTAT WAS SUCCESSFUL FOR OPER1
Command ===>
F1=Help
F2=Main Menu F3=Return
F6=Roll
F12=Cancel
5. Move the cursor to the command line and enter TIMER.
6. AON/SNA displays the active timers on the Timer Management panel.
Sample result:
EZLK6000
Target:
TIMER MANAGEMENT
Target Network ID:
CNM01 NETOP1
10/19/00 08:41:38
1 TO
1 OF
1
Total Selected Timers:
1
Total Purged Timers:
0
Filter criteria:
Type one action code. then press enter.
1|A=Add 2|C=Change 3|P=Purge 4=Add CHRON timer
Timer ID Scheduled
Type Interval Task
Save
_ TA1N500
10/19/00 11:02:36 AFTER
AUTX25MN
FKVEOPFI TA1N500 10 000
Command ===>
F1=Help
F2=Main Menu
F7=Backward F8=Forward
F3=Return
F5=Refresh
Catchup
F6=Roll
F12=Cancel
7. Look for a timer with the timer ID of the NCP name.
8. Press F3 to return to the SNA Automation: X25 LUDRPOOL panel.
To trigger threshold processing:
1. Enter 1 in the Monitor field on the X25 LUDRPOOL panel and change the
value in the Threshold field to a value higher than the number available.
2. AON/SNA updates the SNA Automation: X25 LUDRPOOL panel.
Sample result:
78
Installation: Configuring Additional Components
FKVKX200
SNA Automation: X25 LUDRPOOL
CNM01
NCP name : TA1N500_
Monitor
: 1
(1=Yes
2=No)
Interval : 10
Threshold: 200
FKV651I LUDRPOOL FOR NCP TA1N500 = 104
Command ===>
F1=Help
F2=Main Menu F3=Return
F6=Roll
F12=Cancel
3. Move the cursor to the command line and enter DDF.
4. AON/SNA displays the CNM01 Network Status panel (the DDF menu). On the
DDF menu, the X25 RESOURCES are now highlighted in pink.
Sample panel:
FKVPNSNA
CNM01 NETWORK STATUS
SUBAREA RESOURCES
NCPS
CDRMS
CDRSCS
LINES
LINKS
PUS
APPLS
APPN RESOURCES
CONTROL POINTS
END NODES
X25 RESOURCES
X25 MACHINES
X25 PU SVC INOP
MISCELLANEOUS RESOURCES
5. Move the cursor to X25 RESOURCES and press F8. AON/SNA displays the
CNM01 Network Status - X25 Resources panel. This panel shows your NCP
name in pink.
Sample result:
FKVPNLX1
PAGE 1 OF 1
CNM01 NETWORK STATUS - X25 RESOURCES
TA1N500
6. Move the cursor to the NCP name and press F2. AON/SNA displays the Detail
Status Display panel.
Sample result:
Chapter 2. Defining NetView Components
79
---- DETAIL STATUS DISPLAY ---1 OF
COMPONENT: TA1N500
SYSTEM
COLOR
: PINK
PRIORITY :
DATE
: 10/19/00
TIME
: 09:01:51
REPORTER : AUTX25MN
NODE
: CNM01
1
: CNM01
270
DUPLICATE COUNT:
1 'FKV653E LUDRPOOL FOR NCP TA1N500 = 104 : THRESHOLD = 200'
Testing the X25MONIT Function: To perform the test for the X25MONIT
function, your system must have:
v Active X.25 switched virtual circuit (SVC) links
v At least one switched virtual circuit (SVC) link defined in the configuration file
v DDF customized for X.25
v Started the X25MONIT environment through the configuration file or the
X25INIT command
v Access to an X.25 switched virtual circuit (SVC) device that can start a
connection with a monitored switched virtual circuit (SVC) link
To run the X25MONIT test:
1. Enter X25MONIT. AON/SNA displays the Operator Command Interface: X.25
Monit panel.
Sample result:
FKVKX100
Operator Command Interface: X.25 Monit
CNM01
Type an action code. Then press Enter.
1=Add
2=Change 3=Delete
Res Name
-------STATUS------------SVCs-----Mch Name Group
NCP Name MCH-Li MCH-PU MCH-LU Type Tot Act Busy Free Tmr.
LINE1
2 XL01001 X25S01B TA1N500 ACTIV ACTIV ACTIV INOUT 7 0 0 7
LINE2
_ XL01002 X25S01A TA1N500 ACTIV ACTIV ACTIV IN
1 0 0 7
LINE3
_ XL01003 X25S01C TA1N500 ACTIV ACTIV ACTIV OUT 23 0 0 23
LINE4
_ XL01004 X25S01D TA1N500 ACTIV ACTIV ACTIV INOUT 3 0 0 3
LINE5
_ XL01001 X25S01E TA1N500 ACTIV ACTIV ACTIV OUT
3
0
0 3
Command ===>
F1=Help
F2=Main Menu
F7=Backward F8=Forward
F3=Return F5=Refresh
F12=Cancel
F6=Roll
2. Verify that the values for the Name, Group, NCP, Type, and Total columns are
correct.
3. Check the values for the Active, Busy, and Free columns.
4. Start a connection from your X.25 device.
80
Installation: Configuring Additional Components
5. Press F5 to refresh the panel. AON/SNA decreases the value in the Free
column by 1 and increases the value in the Busy column by 1.
6. Disconnect the X.25 device.
7. Press F5 to refresh the panel. AON/SNA decreases the values for the Busy
column by 1 and increases the values for the Free column by 1.
Setting Up Focal-point Services
A focal point is a domain node that you define in the control file. The focal point
domain is the central control point for information about other domains in your
distributed network. AON routines forward messages to the focal point from the
distributed domains. You can also issue commands and receive responses from the
focal point NetView to distributed NetView programs using AON gateways.
By implementing AON focal point services, you can:
v Enable command facility (NCCF) operators to use the gateway pipelines to send
commands to other NetView domains and receive responses, eliminating the
need for personal NNT sessions for each NCCF operator.
v Manage the RACF passwords for gateway automation operators
v Set up and initiate automated user NNT sessions
v Set up automated user terminal access facility (TAF) full-screen sessions
v Display the status of gateway automation operators, user NNT sessions, and
TAF full-screen sessions.
The AON router establishes and maintains connections between hosts and
forwards messages and alerts from multiple hosts to a single host. Because of this,
network operators can receive all network alert messages at a single console. The
message destination is controlled within the control file. Routed messages identify
the origination host. The router displays the status of host connections in the
operator interface full-screen displays and also in DDF.
Automation Notification Forwarding Design
Automation notifications are messages that describe significant actions detected or
taken by AON. These notifications are necessary to understand and operate the
network. A forwarding facility sends notifications from one NetView to another
NetView. Through a focal point, you can monitor several NetView programs and
their networks from one NetView. AON uses automation notifications to update
DDF. By forwarding notifications, AON provides a consolidated, hierarchical view
of an entire operating environment on the focal point DDF.
To forward notifications between different systems, designate a focal point where
AON sends all notifications. Optionally, you can designate a backup for the
primary focal point. Define the connectivity of the hosts in a tree-structured
hierarchy, so that all notifications are forwarded to the focal point. Figure 8 on
page 82 shows an example of a notification forwarding hierarchy.
Chapter 2. Defining NetView Components
81
Figure 8. Notification Forwarding Hierarchy
In Figure 8, notifications from domains CNM02, CNM03, CNM04, and CNM05 are
forwarded to domain CNM01. Notifications sent from the distributed nodes pass
through CNM02 and are routed to the focal point domain, CNM01. CNM02 also
forwards its own notifications to the focal point. If domain CNM01 is not available,
an alternate path is defined to the backup focal point, CNM99.
Define notification forwarding hierarchy in the FORWARD FOCALPT control file
entry. Each domain has a single FORWARD FOCALPT entry that defines primary
and backup focal points. The FORWARD FOCALPT entry for both the distributed
and intermediate domains in Figure 8 is:
FORWARD FOCALPT,PR=CNM01,BKUP=CNM99
No FORWARD FOCALPT entries are defined for domains CNM01 or CNM99. If
no FORWARD FOCALPT entry is defined or if the domain specified in a
FORWARD FOCALPT entry is the current domain, AON considers the current
domain as the focal point and displays all notifications without forwarding them.
For more information about the FORWARD FOCALPT control file entry, see the
IBM Tivoli NetView for z/OS Administration Reference.
82
Installation: Configuring Additional Components
If the domain specified in the FORWARD FOCALPT entry is not available, AON
logs notifications in the NetView log of the current domain. For example, in
Figure 8 on page 82, if neither domain CNM01 nor its backup focal point, CNM99,
is available, all notifications from domain CNM03 are logged in the NetView log
on domain CNM03.
Gateways
To forward automation notifications and route commands and responses between
NetView domains, AON uses automation operators referred to as gateways. Each
domain has a single automation operator defined as an outbound gateway operator.
The outbound gateway automation operator establishes and maintains all the
connections to other domains. These connections are established when the
outbound gateway operator logs on to the target domain. This logon process
creates an NNT session on the target domain using the operator ID of the original
outbound gateway operator.
On the target domain, the original outbound gateway automation operator is
referred to as the inbound gateway. A domain can have one or more inbound
gateways, depending on the number of domains connected to it.
Default gateway names are formed by combining the GAT prefix with the domain
name. For example, the CNM01 domain outbound gateway automation operator is
named GATCNM01. Similarly, any inbound gateway automation operator name is
the GAT prefix concatenated with the inbound gateway domain name. For
example, the gateway names for three domains, CNM01, CNM02 and CNM03, are
shown in Figure 9. Domain CNM01 is the focal point for notification forwarding
for distributed hosts CNM02 and CNM03.
Figure 9. Gateway Names in a Distributed Network
In Figure 9, using the default naming convention, the outbound gateway
automation operator for domain CNM01 is called GATCNM01. GATCNM01 is also
the inbound gateway automation operator for domains CNM02 and CNM03.
Similarly, GATCNM03, an outbound gateway for domain CNM03, is an inbound
gateway on the focal point domain, CNM01.
You can override default gateway names with the LOGONID parameter of the
GATEWAY control file entry or with the AUTOOPS control file entry.
Chapter 2. Defining NetView Components
83
For each domain, only the outbound gateway task is defined in the control file
using the AUTOOPS entry. In Figure 9 on page 83, the control file entry for domain
CNM01 is:
AUTOOPS GATOPER,ID=GATCNM01
For more information about the AUTOOPS control file entry, see the IBM Tivoli
NetView for z/OS Administration Reference.
In the GATEWAY control file entry, you define domains to which outbound
gateway automation operators connect. In this same definition, you specify the
password that the gateway automation operator uses to log on to other domains.
This password must match the password in the target domain for this outbound
gateway automation operator. In Figure 9 on page 83, the control file entries are for
domain CNM01:
GATEWAY CNM02,PASSWORD=pwd_cnm01,DESC='AON NETVIEW'
GATEWAY CNM03,PASSWORD=pwd_cnm01,DESC='SYSTEM SY2 AON NETVIEW'
Define gateway automation operators to a NetView domain in the DSIOPF
member of the DSIPARM data set. For example, in Figure 9 on page 83 the DSIOPF
entries for domain CNM01 follow:
GATCNM01
OPERATOR
PROFILEN
GATCNM02 OPERATOR
PROFILEN
GATCNM03 OPERATOR
PROFILEN
PASSWORD=pwd_cnm01
EZLPRFAO
PASSWORD=pwd_cnm02
EZLPRFAO
PASSWORD=pwd_cnm03
EZLPRFAO
For more information about the GATEWAY control file entry, see the IBM Tivoli
NetView for z/OS Administration Reference.
Passwords
You do not need to define automation operators to RACF. However, you do need
to define to RACF any ID that is used for an NNT session, even if the ID is used
by an automation operator.
Because gateway automation operators can automatically log on to other NetView
domains, AON must have a way of storing passwords and an automated process
for maintaining them. AON stores passwords in an encrypted format in a VSAM
data set. AON provides an interface for retrieving passwords when necessary.
AON routines automatically change the passwords every 30 days. If you do not
use RACF and the AON automated password management and retrieval, you must
hard code passwords in the GATEWAY control file entry.
Note: NetView provides the option of specifying whether password checking is
performed by NetView or by an SAF security product, such as RACF. The
method of checking is specified by the SECOPTS.OPERSEC setting,
described in the IBM Tivoli NetView for z/OS Administration Reference. If you
specified that password checking is to be performed by NetView, be aware
that any password defined to NetView is automatically converted to
uppercase and stored in uppercase. If you specified that password checking
is to be performed by using an SAF security product, you might be able to
use the mixed case password function that is available in z/OS version 1.7.
When you implement AON automated RACF password management and retrieval,
the following restrictions apply:
84
Installation: Configuring Additional Components
v Gateway automation operator IDs must be defined using the password
NOINTERVAL RACF command. This command is documented in your RACF
manuals.
v AON generates a random eight-character password for the gateway automation
operator. Use the MASK parameter on the ENVIRON RACF control file entry to
specify fewer characters for passwords.
v AON automatically changes passwords every 30 days.
v AON stores the passwords in encrypted format in a VSAM data set, which is
used when AON retrieves the passwords. Restrict access to the command
processor, GETPW, because it retrieves the password from the VSAM data set.
Note: Command authorization checking is NetView security. It stops an operator
from issuing a command. GETPW returns the password to the routine for
logon. Without authorization, an operator can use GETPW to log on as
the gateway operator.
v In a shared RACF data set environment (for example, if two NetView programs
are running in the same host), the ENVIRON RACF control file entry must be
coded using the OWNER or LIST parameters. The domain specified in either of
these two parameters must be the owner of the RACF data sets.
For more information, see “Installing RACF Gateway Automation Operator
Password Option” on page 93.
Note: All non-RACF users must define all of their automation operators to their
SAF product. In addition, for automation operators that are also gateway
operators, store the passwords in the AON password data set. All the
considerations regarding RACF also apply to other SAF products.
Connection
When a domain receives the following message from NetView, its outbound
gateway automation operator tries to connect to all the domains specified in the
GATEWAY entries in its control file:
DSI112I NCCF READY FOR LOGON AND SYSTEM OPERATOR COMMANDS
When the outbound gateway automation operator logs on to the other domains as
the inbound gateway, the inbound gateway sends a command to the outbound
gateway automation operator on each domain to which it connects, requesting to
log. For example, in Figure 9 on page 83, if the DSI112I message is received on
domain CNM01, GATCNM01 attempts to log on to domains CNM02 and CNM03,
which are defined as gateway entries in the control file on domain CNM01. After
GATCNM01 logs on to domains CNM02 and CNM03 as the inbound gateway
operator, it sends messages to GATCNM02 and GATCNM03 asking them to log on
to CNM01. In this way all the domains establish outbound and inbound
connections without user intervention.
In each domain, AON displays the status of gateways through the Dynamic
Display Facility.
Command and Response Routing
After the gateways between NetView domains are established, automation or
NCCF operators can use the outbound gateway to issue commands to another
domain and receive a response from the other domain on the inbound gateway
from that domain. The need for all operators to have personal NNT sessions for
each domain to which they need access is eliminated. The AON SENDCMD
command issues commands across the gateways.
Chapter 2. Defining NetView Components
85
To facilitate command and response routing between different NetView domains,
you can also specify an adjacent NetView with the ADJNETV control file entry.
This entry defines an adjacent NetView domain that acts as intermediary host for
commands and responses between one NetView and another. You can also specify
a backup adjacent domain to be used if the primary adjacent domain is
unavailable. In Figure 10, domains CNM02, CNM03 and CNM04 are distributed
hosts with CNM01 defined as the focal point. To route commands and responses
between domains CNM02 and CNM04, you specify domain CNM03 as the
adjacent domain. Optionally, you can define domain CNM01 as the backup
adjacent domain.
Figure 10. Adjacent NetView Programs
The control file entry for domain CNM02 (as specified in domain CNM04) is:
ADJNETV CNM02,DOMAIN=CNM03,ALTNETV=CNM01,DESC='PASSTHRU to CNM02'
and the control file entry for domain CNM04 in CNM02 is:
ADJNETV CNM04,DOMAIN=CNM03,ALTNETV=CNM01,DESC='PASSTHRU to CNM04'
NetView Definitions
To support notification forwarding, consider the following conditions:
v If an RRD statement does not already exist in the CNMSTUSR or CxxSTGEN
member, add one for each host with which the defined-host directly
communicates. For information about changing CNMSTYLE statements, see IBM
Tivoli NetView for z/OS Installation: Getting Started.
v Automation table statements are required for focal point services. Sample
statements are supplied with AON and do not require modification.
|
|
|
|
Example of Focal Point™ Implementation
Figure 11 on page 87 shows a sample network of five NetView domains. The
definitions required to implement the sample network follow.
86
Installation: Configuring Additional Components
Figure 11. Notification Forwarding Hierarchy
In Figure 11, CNM01 is the primary focal point domain and CNM99 is the backup
focal point. Domains CNM03 and CNM05 include adjacent NetView definitions so
that commands and responses can be routed between them.
Domains CNM01, CNM99, and CNM02 share the same RACF data set. CNM01 is
the owning domain for the shared RACF support, this is specified on the
ENVIRON RACF control file entry for the shared domains. Because CNM01 is the
owning domain, its RACF password is specified on the RACF gateway definitions
for CNM02 and CNM99.
Control File Entries: This section lists the AON control file entries needed to
implement the sample network that is illustrated in Figure 11.
Domain CNM01:
AUTOOPS
ENVIRON
GATEWAY
GATEWAY
ADJNETV
ADJNETV
ADJNETV
GATOPER,ID=GATCNM01
RACF,LIST=(CNM01,CNM99,CNM02)
CNM02,PASSWORD=RACFNNT,DESC='CNM02 intermediate host'
CNM99,PASSWORD=RACFNNT,DESC='CNM99 Backup focal point'
CNM03,DOMAIN=CNM02,DESC='CNM03 distributed node'
CNM04,DOMAIN=CNM02,DESC='CNM04 distributed node'
CNM05,DOMAIN=CNM02,DESC='CNM05 distributed node'
Chapter 2. Defining NetView Components
87
Note: Because no FORWARD FOCALPT entry has been defined, AON treats
domain CNM01 as the focal point and displays all automation notifications
on this domain without attempting to forward them.
Domain CNM99:
AUTOOPS
ENVIRON
FORWARD
GATEWAY
GATEWAY
ADJNETV
ADJNETV
ADJNETV
GATOPER,ID=GATCNM99
RACF,LIST=(CNM01,CNM99,CNM02)
FOCALPT,PRI=CNM01
CNM01,PASSWORD=RACFNNT,DESC='CNM01 Focal point'
CNM02,PASSWORD=RACFNNT,DESC='CNM02 distributed node'
CNM03,DOMAIN=CNM02,DESC='CNM03 distributed node'
CNM04,DOMAIN=CNM02,DESC='CNM04 distributed node'
CNM05,DOMAIN=CNM02,DESC='CNM05 distributed node'
Domain CNM02:
AUTOOPS
ENVIRON
FORWARD
GATEWAY
GATEWAY
GATEWAY
GATEWAY
GATEWAY
GATOPER,ID=GATCNM02
RACF,LIST=(CNM01,CNM99,CNM02)
FOCALPT,PRI=CNM01,BKUP=CNM99
CNM01,PASSWORD=RACFNNT,DESC='CNM01
CNM99,PASSWORD=RACFNNT,DESC='CNM99
CNM03,PASSWORD=RACFNNT,DESC='CNM04
CNM04,PASSWORD=RACFNNT,DESC='CNM05
CNM05,PASSWORD=RACFNNT,DESC='CNM06
Focal point'
Backup Focal Point'
Distributed host'
Distributed host'
Distributed host'
Domain CNM03:
AUTOOPS
FORWARD
ADJNETV
ADJNETV
ADJNETV
GATEWAY
GATEWAY
GATOPER,ID=GATCNM03
FOCALPT,PRI=CNM01,BKUP=CNM99
CNM01,DOMAIN=CNM02,DESC='Adjacent NetView CNM01'
CNM99,DOMAIN=CNM02,DESC='Adjacent NetView CNM99'
CNM05,DOMAIN=CNM04,ALTNETV=CNM02,DESC='Adjacent NetView CNM05'
CNM02,PASSWORD=RACFNNT,DESC='CNM02 Intermediate domain'
CNM04,PASSWORD=RACFNNT,DESC='CNM04 Adjacent Host'
Domain CNM04:
AUTOOPS
FORWARD
ADJNETV
ADJNETV
GATEWAY
GATEWAY
GATOPER,ID=GATCNM04
FOCALPT,PRI=CNM01,BKUP=CNM99
CNM01,DOMAIN=CNM02,DESC='Adjacent NetView CNM01'
CNM99,DOMAIN=CNM02,DESC='Adjacent NetView CNM99'
CNM02,PASSWORD=RACFNNT,DESC='CNM02 Intermediate domain'
CNM05,PASSWORD=RACFNNT,DESC='CNM05 Adjacent Host'
Domain CNM05:
AUTOOPS
FORWARD
ADJNETV
ADJNETV
ADJNETV
GATEWAY
GATEWAY
GATOPER,ID=GATCNM05
FOCALPT,PRI=CNM01,BKUP=CNM99
CNM01,DOMAIN=CNM02,DESC='Adjacent NetView CNM01'
CNM99,DOMAIN=CNM02,DESC='Adjacent NetView CNM99'
CNM03,DOMAIN=CNM04,ALTNETV=CNM02,DESC='Adjacent NetView CNM03'
CNM02,PASSWORD=RACFNNT,DESC='CNM02 Intermediate domain'
CNM04,PASSWORD=RACFNNT,DESC='CNM04 Adjacent Host'
NetView DSIPARM DSIOPF Entries: This section lists the NetView DSIPARM
DSIOPF member entries needed to implement the sample network illustrated in
Figure 11 on page 87.
Domain CNM01:
GATCNM01 OPERATOR
PROFILEN
GATCNM02 OPERATOR
PROFILEN
GATCNM99 OPERATOR
PROFILEN
88
PASSWORD=RACFNNT
EZLPRFAO
PASSWORD=RACFNNT
EZLPRFAO
PASSWORD=RACFNNT
EZLPRFAO
Installation: Configuring Additional Components
Domain CNM99:
GATCNM01 OPERATOR
PROFILEN
GATCNM02 OPERATOR
PROFILEN
GATCNM99 OPERATOR
PROFILEN
PASSWORD=RACFNNT
EZLPRFAO
PASSWORD=RACFNNT
EZLPRFAO
PASSWORD=RACFNNT
EZLPRFAO
Domain CNM02:
GATCNM01 OPERATOR
PROFILEN
GATCNM02 OPERATOR
PROFILEN
GATCNM03 OPERATOR
PROFILEN
GATCNM04 OPERATOR
PROFILEN
GATCNM05 OPERATOR
PROFILEN
GATCNM99 OPERATOR
PROFILEN
PASSWORD=RACFNNT
EZLPRFAO
PASSWORD=RACFNNT
EZLPRFAO
PASSWORD=RACFNNT
EZLPRFAO
PASSWORD=RACFNNT
EZLPRFAO
PASSWORD=RACFNNT
EZLPRFAO
PASSWORD=RACFNNT
EZLPRFAO
Domain CNM03:
GATCNM02 OPERATOR
PROFILEN
GATCNM03 OPERATOR
PROFILEN
GATCNM04 OPERATOR
PROFILEN
PASSWORD=RACFNNT
EZLPRFAO
PASSWORD=RACFNNT
EZLPRFAO
PASSWORD=RACFNNT
EZLPRFAO
Domain CNM04:
GATCNM02 OPERATOR
PROFILEN
GATCNM03 OPERATOR
PROFILEN
GATCNM04 OPERATOR
PROFILEN
GATCNM05 OPERATOR
PROFILEN
PASSWORD=RACFNNT
EZLPRFAO
PASSWORD=RACFNNT
EZLPRFAO
PASSWORD=RACFNNT
EZLPRFAO
PASSWORD=RACFNNT
EZLPRFAO
Domain CNM05:
GATCNM02 OPERATOR
PROFILEN
GATCNM04 OPERATOR
PROFILEN
GATCNM05 OPERATOR
PROFILEN
|
|
PASSWORD=RACFNNT
EZLPRFAO
PASSWORD=RACFNNT
EZLPRFAO
PASSWORD=RACFNNT
EZLPRFAO
NetView RRD Entries: This section lists the NetView RRD entries in the
CNMSTYLE member that are required to implement the sample network
illustrated in Figure 11 on page 87.
Domain CNM01:
RRD.CNM02 = *
RRD.CNM99 = *
Domain CNM99:
RRD.CNM01 = *
RRD.CNM02 = *
Domain CNM02:
Chapter 2. Defining NetView Components
89
RRD.CNM01
RRD.CNM03
RRD.CNM04
RRD.CNM05
RRD.CNM99
=
=
=
=
=
*
*
*
*
*
Domain CNM03:
RRD.CNM02 = *
RRD.CNM04 = *
Domain CNM04:
RRD.CNM02 = *
RRD.CNM03 = *
RRD.CNM05 = *
Domain CNM05:
RRD.CNM02
RRD.CNM04
= *
= *
RACF Definitions: It is assumed that the VSAM RACF password database
(NETVIEW.CNM01.PASSWORD) was successfully allocated when you ran the
VSAM allocation job CNMSJ004 during NetView installation.
RACF Considerations: Because domains CNM01, CNM02, and CNM99 share the
same RACF data set, you must define the following gateway operators in that data
set:
v GATCNM01
v GATCNM02
v GATCNM99
v GATCNM03
v GATCNM04
v GATCNM05
You must also define the following gateway operators in the data sets indicated:
RACF data set Gateway operators
CNM03
GATCNM02 and GATCNM04
CNM04
GATCNM02, GATCNM03 and GATCNM05
CNM05
GATCNM02 and GATCNM04
AON Considerations: You must issue the GETPW command on each domain with
the following operands to initialize the VSAM RACF password data set with the
passwords for gateway operators. The password field contains the actual password
for the outbound gateway operator to log on to the specified domain.
For domain CNM01, issue:
* GETPW GATCNM01 CNM01,INIT=password
For domain CNM99, issue:
* GETPW GATCNM99 CNM01,INIT=password
For domain CNM02, issue:
* GETPW
GETPW
GETPW
GETPW
90
GATCNM02
GATCNM02
GATCNM02
GATCNM02
CNM01,INIT=password
CNM03,INIT=password
CNM04,INIT=password
CNM05,INIT=password
Installation: Configuring Additional Components
For domain CNM03, issue:
GETPW GATCNM03 CNM02,INIT=password
GETPW GATCNM03 CNM04,INIT=password
For domain CNM04, issue:
GETPW GATCNM04 CNM02,INIT=password
GETPW GATCNM04 CNM03,INIT=password
GETPW GATCNM04 CNM05,INIT=password
For domain CNM05, issue:
GETPW GATCNM05 CNM02,INIT=password
GETPW GATCNM05 CNM04,INIT=password
Note: Entries marked with an asterisk (*) are necessary only if this is the owning
RACF domain.
CNM01, CNM99, and CNM02 share the same RACF password data set. The shared
relationship is defined on the ENVIRON RACF entry in one of two ways:
v ENVIRON RACF OWNER=CNM01 SHARE=(CNM02,CNM99)
v ENVIRON RACF LIST=(CNM01,CNM02,CNM99)
Specify one domain, CNM01 in this case, as the owning domain.
With shared RACF, you specify the outbound gateway operator ID and RACF
owner domain in all sharing systems. Table 16 illustrates how the GETPW
command differs in a shared and nonshared RACF environment.
Table 16. Comparison of shared and non-shared RACF environment
Domain
Command
Non-shared RACF
Shared RACF
CNM01
GETPW
GATCNM01 CNM99 pwd
GATCNM01 CNM02 pwd
GATCNM01 CNM01 pwd
CNM99
GETPW
GATCNM99 CNM01 pwd
GATCNM99 CNM02 pwd
GATCNM99 CNM01 pwd
CNM02
GETPW
GATCNM02 CNM01 pwd
GATCNM02 CNM99 pwd
GATCNM02 CNM01 pwd
Implementing Notification Forwarding
It is best to implement notification forwarding in a top-down approach, defining
focal points first, then the distributed hosts. This approach works best because the
focal point is ready to handle the forwarded messages when message forwarding
is turned on in remote hosts.
With a top-down approach, if message forwarding is not yet implemented, AON
displays messages at remote hosts to notification operators. After you have enabled
message forwarding, AON routes messages to the focal point specified.
In summary, the tasks required to implement notification forwarding in a focal
point environment include:
|
|
v Designing your notification forwarding hierarchy.
v Tailoring NetView definitions (in the CNMSTUSR or CxxSTGEN member). For
information about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started.
v Defining the focal point and backup focal point control file entries (FORWARD
FOCALPT).
Chapter 2. Defining NetView Components
91
v
v
v
v
Defining the outbound gateway operator entries (AUTOOPS)
Defining the inbound gateway operator entries (GATEWAY and ADJNETV).
Adding NetView outbound and inbound operator IDs (DSIOPF).
Initializing the NetView outbound and inbound operator IDs and passwords.
Notification Forwarding Example: For this example, assume that the AON
operator AONNET2 wants to forward a request (AON notify) to CNM99 from
CNM01. The outbound gateway operator for CNM01 is GATCNM01. The
outbound gateway operator for CNM02 is GATCNM02. The outbound gateway
operator for CNM99 is GATCNM99. The inbound gateway operator for CNM02
that receives notifications from CNM01 is GATCNM01. The inbound gateway
operator for CNM99 that receives notifications from CNM02 is GATCNM02.
The program sends the request to the CNM01 outbound gateway operator
(GATCNM01). The outbound gateway operator determines if the request is for the
CNM01 domain. In this case, it is not. The outbound gateway operator then routes
the request to the inbound gateway operator in domain CNM02 (GATCNM01)
from domain CNM01. When the inbound gateway operator receives the request, it
sends the request to the outbound gateway operator for CNM02 (GATCNM02).
The outbound gateway operator for CNM02 determines whether the forwarded
request is for this domain. In this case, it is not. The outbound gateway operator
then routes the request to the inbound gateway operator in domain CNM99
(GATCMM02) from domain CNM02. When the inbound gateway operator receives
the request, it sends the request to the outbound gateway operator for CNM99
(GATCNM99). The outbound gateway operator for CNM99 determines whether
the forwarded request is for this domain. In Figure 12 the request is for this
domain, so it issues the request.
CNM01
O
CNM02
I
O
O - GATCNM01
CNM99
O - GATCNM02
I - GATCNM01
I
O
O - GATCNM99
I - GATCNM02
O = Outbound operator gateway
I = Inbound operator gateway
Figure 12. Notification Forwarding Example
Table 17 on page 93 lists the control file entries that are needed to accomplish the
notification forwarding illustrated in Figure 12.
92
Installation: Configuring Additional Components
Table 17. Example of the Required Control File Entries for Notification Forwarding
Domain
Control file entries
CNM01
AUTOOPS
GATEWAY
ADJNETV
FORWARD
CNM02
AUTOOPS
GATEWAY
GATEWAY
FORWARD
CNM99
AUTOOPS
GATEWAY
ADJNETV
FORWARD
GATOPER,ID=GATCNM01
CNM02,DESC='NEXT DOMAIN',
PASSWORD=xxxx
CNM99,DOMAIN=CNM02
FOCALPT,PRI=CNM99
GATOPER,ID=GATCNM02
CNM99,DESC='NEXT DOMAIN',
PASSWORD=xxxx
CNM01, DESC='
FOCALPT,PRI=CNM99
GATOPER,ID=GATCNM99
CNM02,DESC='NEXT DOMAIN',
PASSWORD=xxxx
CNM01,DOMAIN=CNM02
FOCALPT,PRI=CNM99
Installing RACF Gateway Automation Operator Password Option
Note: Before you install the RACF gateway automation operator password option,
ensure that the conditions as specified in “NetView RRD Entries” on page
89 are acceptable.
Use the following steps to install the RACF option:
1. Allocate a VSAM data set for the RACF gateway passwords (see “Allocate
VSAM Data Set”).
2. Define gateway operator IDs to RACF (see “Define Gateway Operators to
RACF” on page 94).
3. Use the GETPW command processor (see “Initialize Passwords in the Password
Data Set” on page 94) to set the gateway operator ID passwords in the VSAM
data set.
4. In a shared RACF data set environment, code the control file ENVIRON RACF
entry.
5. Schedule a recycle of NetView.
Allocate VSAM Data Set: The CNMSJ004 job (contained in the
NETVIEW.V5R4USER.INSTALL data set) defines the VSAM cluster for the RACF
save password facility for gateway automation operators. You already ran this job
during NetView installation. To rerun this job to allocate the VSAM RACF
password database NETVIEW.CNM01.PASSWORD follow these steps:
1. Review AON IDCAMS member EZLSI101. This is where the VSAM cluster
information is located for the RACF password data set.
2. If you are reallocating NETVIEW.CNM01.PASSWORD, edit CNMSID01 to
delete the existing database so that you can allocate a new database.
3. Rerun CNMSJ004 to allocate the VSAM RACF password database.
Before rerunning the job, update the DASD type, database name, and any other
information that is unique to your environment. Ensure that you are allocating
only the VSAM RACF password database.
Update the NetView Start Procedure: If you allocated the VSAM RACF password
database NETVIEW.CNM01.PASSWORD, add the following DD statement to the
NetView start procedure:
Chapter 2. Defining NetView Components
93
//EZLPSWD DD
DSN=NETVIEW.CNM01.PASSWORD,
//
DISP=SHR,AMP='AMORG,BUFNI=10,BUFND=5'
Define Gateway Operators to RACF: The RACF administrator must define the
gateway operator IDs using the PASSWORD NOINTERVAL RACF command. The
password for the gateway operator is eight characters. You can specify fewer
characters for passwords by using the MASK parameter of the ENVIRON RACF
control file entry.
Initialize Passwords in the Password Data Set: In a RACF environment, the
password you store in the AON data set depends on whether you are using shared
RACF. In a non-shared environment, issue the GETPW command using the INIT
option for each domain. This enables AON routines to retrieve and manage the
RACF passwords for the gateway automation operators. In a shared environment,
issue the GETPW command for only the owning domain. Table 16 on page 91
compares the GETPW command for shared and non-shared environments. See
“GETPW - Gateway Password Maintenance” for more information. “Passwords”
on page 84 also contains additional information about password checking in a
RACF environment.
GETPW - Gateway Password Maintenance
The GETPW command processor maintains a VSAM file containing passwords
used by gateway automation operators when establishing NNT sessions. The
records in the data set are keyed using a combination of the user ID and domain
ID. Each record has the following fields:
v Current password field
v New password field
v Date-password-last-changed field
The passwords are stored in encrypted format and changed every 30 days. For the
details and syntax of the GETPW command, see the NetView online help.
|
|
Note: If a shared RACF is specified on the ENVIRON RACF entry, when a
non-owning gateway operator wants to sign on to one of the shared
domains, the operator issues the following command:
GETPW gatoperid owning_domain,READ
In the following example, GETPW stores the value specified with the INIT
parameter in the VSAM data set, with a key of GATCNM01CNM02 (the user ID
and the domain ID).
GETPW GATCNM01 CNM02,INIT=pswd001
In the following example, GETPW retrieves the password from the VSAM data set
that allows GATCNM01 to log on to CNM02.
GETPW GATCNM01 CNM02,READ
In the following example, GETPW deletes the password from the VSAM data set
that GATCNM01 uses to log on to CNM02.
GETPW GATCNM01 CNM02,DELETE
Defining RMTCMD Gateway Sessions
Each NNT gateway session can also have a RMTCMD session defined. Several
functions (i.e.: Inform Policy and TCP/IP for MVS) use the RMTCMD session to
route requests to other NetView domains.
94
Installation: Configuring Additional Components
If you have 3 domains as shown in Figure 13, then in addition to the NNT
gateway sessions you also have RMTCMD gateway sessions that use a task prefix
of RMT.
GATCNM02/RMTCNM02
CNM02
GATCNM03/RMTCNM03
CNM01
GATCNM01/RMTCNM01
CNM03
GATCNM01/RMTCNM01
Figure 13. Gateway Names in a Distributed Network
The CDLOG statement is used to define the RMT operator and RMTCMD sessions.
For details on CDLOG see the IBM Tivoli NetView for z/OS Administration Reference.
Examples:
To define a session from CNM01 to CNM03 in EZLCFG01 for domain CNM01:
CDLOG
GATCNM01.CNM03,
SESSTYPE=RMT,
TARGOP=RMTCNM01,
INIT=YES,
DESC='RMTCMD GATEWAY to CNM03'
This allows RMTCMD requests to flow from CNM01 to CNM03.
To define a session from CNM03 to CNM01 in EZLCFG01 for domain CNM03:
CDLOG
GATCNM03.CNM01,
SESSTYPE=RMT,
TARGOP=RMTCNM03,
INIT=YES,
DESC='RMTCMD GATEWAY to CNM01'
Add the appropriate operator ids in DSIOPF for each domain.
Chapter 2. Defining NetView Components
95
96
Installation: Configuring Additional Components
Chapter 3. Configuring the Operator Environment
The following topics describe aspects of the operator environment that you can
customize:
v “Defining NetView Operators”
v “Specifying the Degree of Security Verification”
v “Defining Operator Data Sets” on page 98
v “Assigning Operators to Groups” on page 98
v “Suppressing Commands After Entry” on page 98
v
v
v
v
“Defining PA and PF Keys” on page 99
“Defining Hardcopy Printers” on page 99
“Setting Initial Defaults” on page 100
“Defining Domains Where This NetView Program Can Establish Cross-Domain
Communication” on page 100
Defining NetView Operators
You can define your NetView operators either by using an SAF security product,
through DSIPARM member DSIOPF, or both. For detailed information about
defining NetView operators, refer to the IBM Tivoli NetView for z/OS Security
Reference.
NetView operators, using the RMTCMD command, can issue commands from the
NetView program running on your local system to a NetView program running on
a remote system. When the operator issues a RMTCMD command and is not
already logged on to the remote system, NetView logs the operator onto the
remote system as a distributed autotask.
The operator can specify a logon ID on the RMTCMD command. However, if a
logon ID is not specified, the NetView program uses the operator logon ID from
the local system as the default logon ID for the distributed autotask session.
If you want operators to issue RMTCMD commands without specifying a logon ID
for each command, ensure that each operator has a unique logon ID on all the
systems to which RMTCMD commands are issued.
Specifying the Degree of Security Verification
|
|
|
You can define the degree of security verification to be performed when an
operator logs on by using the SECOPTS statements in the CNMSTUSR or
CxxSTGEN member. For information about changing CNMSTYLE statements, see
IBM Tivoli NetView for z/OS Installation: Getting Started.
|
|
|
Use the REFRESH command to refresh many types of security used while the
NetView program is running. The REFRESH command can be used to change the
security settings in the CNMSTUSR or CxxSTGEN member. For information about
changing CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation:
Getting Started.
© Copyright IBM Corp. 2001, 2009
97
If you want information about...
Refer to...
SAF checking
IBM Tivoli NetView for z/OS Security Reference
REFRESH command
IBM Tivoli NetView for z/OS Command
Reference Volume 1 (A-N)
Defining Operator Data Sets
You can set up partitioned data sets (PDSs) which contain members that apply
only to specific operators, for example, PF key definitions and command lists. To
do this, follow these steps:
1. Decide on a naming convention for such data sets and allocate them. The
default naming convention is NETVIEW.OPDS.opid where opid is the operator ID
associated with each such data set.
2. In the CNMSTUSR or CxxSTGEN member, set a common global variable called
OpDsPrefix to your operator data set prefix. For information about changing
CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation: Getting
Started. The default is NETVIEW.OPDS. You can use the RESTYLE command to
enable the change without recycling the NetView program.
3. Set up the logon profile for each such operator to issue OVERRIDE commands
that define data sets that are to be specific for that operator. LOGPROF1
(CNME1049) starts with the OpDsPrefix common global variable, or default
naming convention, and appends the operator name to set up an operator data
set for DSICLD and DSIOPEN. This enables CLISTs and PF-key definitions that
are specific to this operator to be kept in this data set.
4. Ensure each such operator is authorized to read from the data sets intended for
that operator. To save current PF-key settings, an operator must have write
authority to the data set associated with the DSIOPEN DD. The DISPFK
command displays and saves PF keys.
|
|
|
|
5. Add appropriate members to these data sets. See the IBM Tivoli NetView for
z/OS Command Reference Volume 1 (A-N) for OVERRIDE and DISPFK for more
information.
Assigning Operators to Groups
You can route messages to groups of operators. To define operator groups, use the
ASSIGN statement:
ASSIGN.groupname.GROUP = list
Where:
groupname
Is the 1–7 character group name
list
Is the list of operator names separated by blanks or commas.
If you want information about...
Refer to...
Group names
IBM Tivoli NetView for z/OS Automation Guide
Suppressing Commands After Entry
If the operator types a suppression character before a command, the command is
not shown on the terminal screen, hardcopy log, or NetView log. On the terminal
screen, the operator sees the command as it is typed, but the NetView system does
not echo the command to the screen after it is entered. The default suppression
98
Installation: Configuring Additional Components
|
|
|
|
|
|
|
character in the CNMSTYLE member is the question mark (?). To change this
suppression character, use the SUPPCHAR statement in the CNMSTUSR or
CxxSTGEN member, and update the statement for your environment. For
information about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started. To prevent an operator from suppressing
commands, comment out the SUPPCHAR statement in the CNMSTUSR or
CxxSTGEN member.
Note: If the text of one command is imbedded in another command, for example
with EXCMD, enter the suppression character as the first character on the
command line or the command buffer, as shown here:
?EXCMD OPER1,SDOM PASSWORD=XYZ
Defining PA and PF Keys
During logon to the NetView program, an operator runs the PFKDEF command
list, CNME1010, which (as a default) references keys defined in the sample
CNMKEYS. This command can also be included in the operator profile.
To change the NetView default PF key settings or the default line of text at the
bottom of many NetView panels that describes PF key settings, modify CNMKEYS.
For specific information about modifying CNMKEYS, refer to the IBM Tivoli
NetView for z/OS Customization Guide.
Defining Hardcopy Printers
|
|
|
|
If you print terminal activity as it occurs, define printers using a HARDCOPY
statement in the CNMSTUSR or CxxSTGEN member. For information about
updating CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation:
Getting Started.
A printer is not defined in the samples. The HARDCOPY statement has the
following format:
HARDCOPY = luname1 luname2 ...
Where:
luname
Is the LU name (1–8 characters) of the printer as it is defined to VTAM.
Define as many printers as you need.
Several operators can share one printer, but each operator can print to only one at
a time. If too many operators share the same printer, messages can be delayed by
being queued at the printer. The NetView program cannot share a printer with
another application or with another NetView program.
The hardcopy devices you define must be LU type 0 and LU type 1, or must use
an LU type 0 or LU type 1 logmode entry. Printers attached to SNA controllers as
LU type 1 logical units can use the M3287SCS logmode. LU type 2 and LU type 3
printers are not supported.
Chapter 3. Configuring the Operator Environment
99
Notes:
1. When you start a session, the NetView program checks the RU size you
specified in the logmode. If you specify 0, the NetView program uses the
default RU size of 4096 bytes. If you enter an RU size, it must be a minimum of
256 bytes.
2. The NORMQMAX value in the member specified by the SCRNFMT parameter
of the DEFAULTS command or the default value supplied by the NetView
product (3000) applies to hardcopy printers. Hardcopy printers can get
backlogged because they are slow or because they run out of paper.
|
|
If you want information about...
Refer to...
NORMQMAX definition statement
IBM Tivoli NetView for z/OS Administration
Reference
Setting Initial Defaults
The following DEFAULTS statement sets initial NetView system defaults:
DEFAULTS.NetLog = Yes
DEFAULTS.SysLog = No
DEFAULTS.HcyLog = Yes
DEFAULTS.CMD = HIGH
DEFAULTS.AUTOLOGN=yes
DEFAULTS.EVERYCON = yes
DEFAULTS.MAXABEND = 4
DEFAULTS.MAXLOGON = 5
DEFAULTS.AUTOSEC = BYPASS
DEFAULTS.MAXCPU = 95
DEFAULTS.STRTSERV=STRTPROC
You can change values as needed for your system.
If you want information about...
Refer to...
DEFAULTS values
IBM Tivoli NetView for z/OS Command
Reference Volume 1 (A-N) for the DEFAULTS
command
Defining Domains Where This NetView Program Can Establish
Cross-Domain Communication
The resource routing definition (RRD) statements in the CNMSTYLE member
define the domains with which the NetView program can establish cross-domain
sessions using NNT sessions. The CNMSTYLE member contains the following
RRD statements:
|
|
*RRD.CNM01 = *
*RRD.CNM02 = *
Where:
CNM01
|
Is the network NETA NetView domain as it is coded on the
DOMAIN keyword in the CNMSTYLE member.
CNM02, CNM99
Are the network NETA NetView domains of the cross-domain
NetView systems.
100
Installation: Configuring Additional Components
|
|
|
Use the CNMSTUSR or CxxSTGEN member to create an RRD statement for this
NetView system and for each cross-domain NetView system so that this NetView
system can establish cross-domain communication. When you include the RRD
statement for this NetView system, you can use the same table of RRD statements
for each NetView system. Specify each domain in a separate RRD statement. If you
are using the RMTCMD command for cross-domain communication, RRD
statements are not necessary. For information about changing CNMSTYLE
statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
If you are using alert, message, and status forwarding, an RRD statement is
required for each domain that is sending alerts, messages, or status to this domain
and for each domain to which this domain is sending alerts, messages, and status.
Chapter 3. Configuring the Operator Environment
101
102
Installation: Configuring Additional Components
Chapter 4. Installing and Configuring the Web Application
This chapter provides information about Web application servers and Web
applications, installing the NetView Web application, defining the NetView Web
server interface task (DSIWBTSK), setting up access to the Web application, and
configuring the 3270 console for the Web application.
Understanding Web Application Servers and Web Applications
The following concepts are important to understanding Web access into the
NetView program:
v The relationship between the HTTP server and Web application server.
Note: In this section, any mention made of HTTP or an HTTP server also
applies to HTTPS or an HTTPS server because either connection is
supported.
v The Web applications defined to the application server, including servlets, Web
application archive files, and XML configuration files.
Web Application Server
|
|
The NetView Web application code runs under the control of a Web application
server, which is supported by an HTTP server (or HTTPS server). WebSphere
Application Server generally runs with the IBM HTTP server; the embedded
version of IBM WebSphere Application Server V7.0 contains an embedded HTTP
server or HTTPS server.
The HTTP server is responsible for listening to a TCP/IP port for requests. When
an HTTP or HTTPS request arrives, the server checks the requested URL against a
set of Web addresses defined with the Web application server. If the Web address
is defined in the web.xml file on the Web application server, the code on that
server is used to process the request.
Web and Enterprise Applications
|
Web applications are application server entities that consist of HTML, Java™ server
pages, and JavaScript™ and Java code. The Java code acts as an extension to the
application server and is grouped into units called servlets. Servlets are similar to
Java applets, but they run under the application server instead of the browser.
With the NetView Web application, the servlets supplied by the NetView product
process the URL requests for connectivity to the NetView program. These servlets
are included in the NetView Web application. To simplify the installation of
applications, the servlets are packaged into jar-style archive files called WAR files,
where .war is the file extension of the archive file, and the WAR file is packaged
into a jar-style archive file called an EAR file, where .ear is the file extension of the
archive file.
WAR file archives adhere to a standard directory convention. The root of the
archive is the document root for the application, and contains HTML files and
other static content, such as graphic files and Java server pages. Under this root
directory is a WEB-INF directory, which can contain the configuration file for the
application, CLASSES, and LIB directories to store class files or jar files as required
by the application.
© Copyright IBM Corp. 2001, 2009
103
The configuration file located in the WEB-INF directory is named web.xml. This
file defines the servlets that are packaged with the NetView Web application and
specifies the URLs that drive the servlets. You can customize this file with the Web
XML editing utility that is provided with the NetView program, with a text editor,
or, if you are using WebSphere Application Server, with the editor that is supplied
with WebSphere Application Server. For information about using the editing utility,
see the online help.
|
|
In addition to Web applications, WebSphere Application Server supports the
concept of enterprise applications. Enterprise applications can contain collections of
Web applications and support features not currently utilized by the NetView
program, such as enterprise JavaBeans™. For WebSphere Application Server, the
NetView Web application is packaged as an enterprise application. These
applications are packaged in archive files with a file type of .ear. The NetView
enterprise application under WebSphere Application Server is the NetView Web
application.
Installing the NetView Web Application
The NetView Web application consists of the following components:
v WebSphere Enterprise Archive (EAR) file
v The embedded version of IBM WebSphere Application Server
v Web XML editing utility (for editing the web.xml file)
|
If you are using WebSphere Application Server as your Web application server,
install the WebSphere Enterprise Archive (EAR) file zNetViewWebApp.ear.
|
The embedded version of IBM WebSphere Application Server is shipped as part of
the NetView Web application and acts as your Web application server if
WebSphere Application Server is not installed.
|
For instructions on installing and setting up your Web application server
environment, refer to the Web application readme file
znetview_webapp_readme_en.htm in the drive:/readmes directory on the NetView
V5R4 DVD or in the netview_installation_dir/doc directory.
|
Note: The readme file also provides information about using the nvsrvc utility to
start, stop, or configure the Web server.
|
If you want information about...
Refer to...
Installing and setting up the NetView Web
application
Web application readme file
Using the NetView Web application
IBM Tivoli NetView for z/OS User’s Guide: Web
Application
Defining the NetView Web Server Interface Task (DSIWBTSK)
To define the NetView Web server interface task, perform the following actions:
v To start the DSIWBTSK Web server interface task automatically, use the
TASK.DSIWBTSK statement in the CNMSTUSR or CxxSTGEN member, and
change INIT=N to INIT=Y. For information about changing CNMSTYLE
statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
|
|
|
|
TASK.DSIWBTSK.INIT=Y
104
Installation: Configuring Additional Components
|
|
|
v Modify CNMSTYLE statements as needed by using the CNMSTUSR or
CxxSTGEN member. For information about changing CNMSTYLE statements,
see IBM Tivoli NetView for z/OS Installation: Getting Started.
WEB statements specify the port and number of sockets for receiving and
sending data on the NetView Web application server:
– WEB.PORT identifies the port for the TCP/IP connection.
– WEB.SOCKETS specifies how many Web browser users can be connected to
the NetView program through TCP/IP.
– WEB.TCPANAME identifies the procedure that is used to start the TCP/IP
address space.
SECOPTS.WEBAUTH specifies whether the NetView Web application checks to
see if an operator ID is authorized to access the NetView program from a Web
browser.
v If you are using a security product such as RACF, define DSIWEB (an autotask)
in the NetView segment. DSIWEB is started by DSIWBTSK during task
initialization.
You might want to restrict access to the DSIWEB task from the EXCMD
command by using the NetView command authorization table or an SAF
product such as RACF.
v To encrypt the data passing between DSIWBTSK and the NetView Web
application server, specify the encryption keys for DSIWBTSK in DSITCPRF
under the WEB_SERVER keyword. The same set of encryption keys must be
specified for the NetView Web application server.
|
|
When the DSIWBTSK DST is started, it establishes communication with TCP/IP
using the port number that is specified in DSIWBMEM or WEB.PORT in the
CNMSTYLE member. DSIWBTSK also starts the autotask DSIWEB, if it is not
already active.
Notes:
1. DSIWEB must have read access to DD CNMPNL1.
2. You might want to restrict access to the DSIWEB task from the EXCMD
command by using the NetView command authorization table, or an SAF
product such as RACF.
For more information, see the IBM Tivoli NetView for z/OS Security Reference.
If you want information about...
Refer to...
Defining the NetView Web server interface
task
IBM Tivoli NetView for z/OS Security Reference
Setting Up Access for the Web Application
The Web address required for browsers to communicate with the NetView
program includes the protocol, the host name or IP address of the application
server, the HTTPS server port number, the NetView Web application context root,
and the individual servlet path. For example:
https://Web_application_server:port/netview/domain_ID/
where either https:// (the default) or http:// is the protocol,
Web_application_server is the application server host name, port is the port on which
the HTTPS server is listening, netview is the NetView Web application context root,
Chapter 4. Installing and Configuring the Web Application
105
and domain_ID is the path of the access servlet. The access servlet path is defined
in the web.xml file with two URL patterns, /domain_ID/* and /domain_ID/action/* for
example.
Note: The Web application context root is shipped as /netview and must not be
modified. The Web addresses that drive the NetView servlets include
/netview in the path.
As stated previously, the web.xml file within the WAR file structure defines the
Web addresses that drive the servlets. The application context root (/netview) is
not defined in the WAR file structure but is determined by application server
configuration. With WebSphere Application Server, an application.xml file within
the EAR file structure defines an application context root of /netview.
The first time an operator attempts to access the NetView program, they are
prompted for a valid NetView operator ID and password. If the specified operator
ID is not already logged on, the NetView program starts it as an autotask.
Connectivity to the Web is accomplished by interaction between the NetView
program and a Web application server. The Web application server can be either
WebSphere Application Server or the embedded version of IBM WebSphere
Application Server. To access the NetView program from your Web browser,
specify a Web address containing the Web application server name, port, and the
NetView system identifier. This Web address drives code supplied by the NetView
product that runs under the Web application server, which opens a socket and
communicates directly with the NetView program. Connections can optionally be
encrypted and operator IDs and passwords are authenticated using SAF facilities
or internal NetView security. A password phrase can be used as a substitute for a
password if an SAF product, such as RACF, is being used for authentication.
|
|
|
|
|
|
Changing the First Task Displayed
To define which task is initially displayed in the work area when users sign in to
the Web application, use the optional webmenu.initpage statement in the
CNMSTWBM member. If you do not define a task using the webmenu.initpage
statement, the About view is initially displayed in the work area. For information
about the webmenu.initpage statement, see the IBM Tivoli NetView for
z/OS Administration Reference or the CNMSTWBM member.
|
|
|
If you want information about...
Refer to...
Changing the task displayed when users sign IBM Tivoli NetView for z/OS Administration
in to the NetView Web application
Reference or the CNMSTWBM member
|
Controlling Access to Tasks
NetView Web application users can access only the tasks for which they are
authorized. Any task for which a user is not authorized is not displayed in the
Web application portfolio for that user. You can define any of the Web application
tasks as a reserved task and define the set of users who are authorized to access
the reserved tasks.
To set this, use the webmenu.reserveusers statement in the CNMSTWBM member.
For more information about defining reserved tasks and the users who can access
them, see the IBM Tivoli NetView for z/OS Security Reference, the IBM Tivoli NetView
for z/OS Administration Reference, and the CNMSTWBM member.
|
106
Installation: Configuring Additional Components
If you want information about...
Refer to...
Controlling access to tasks in the NetView
Web application portfolio
IBM Tivoli NetView for z/OS Security Reference,
IBM Tivoli NetView for z/OS Administration
Reference, and the CNMSTWBM member
Using the NetView Web application
IBM Tivoli NetView for z/OS User’s Guide: Web
Application
|
Configuring User Preferences
Operator settings and preferences for the NetView Web application are stored in
the WebSphere temporary directory, which is similar to one of the following
directories:
v For WebSphere: websphere_installation_path/profiles/default
v For embedded WebSphere: netview_installation_dir/ewas/profiles/profile
A settings file contains information about tasks such as selections and entry fields,
so that when an operator returns to a task view, the last state of the view is
restored. A preferences file contains information from the Set User Preferences task.
The settings files are named operatorID_NVdomain_settings.xml, and the
preferences files are named operatorID_preferences.xml, where operatorID is a
NetView operator ID and NVdomain is a NetView domain.
Note: If you move the NetView Web application to a different Web server, and you
want to carry over the existing operator settings and preferences, you need
to move all settings and preferences files from the temporary directory on
the old server to the temporary directory on the new server.
|
|
You can also set whether some users have override authority for user preferences,
that is, they can set and control the user preferences for other users. To set this, use
the webmenu.prefoverride statement in the CNMSTWBM member. For more
information see the IBM Tivoli NetView for z/OS Administration Reference or
CNMSTWBM.
If you want information about...
Refer to...
Setting user preference overrides in the
NetView Web application
IBM Tivoli NetView for z/OS Administration
Reference or the CNMSTWBM member
Setting user preferences in the NetView Web
application
IBM Tivoli NetView for z/OS User’s Guide: Web
Application
Configuring the Web Application To Display Performance Data
To enable the display in the Web application of the performance data provided by
the IBM Tivoli OMEGAMON XE for Mainframe Networks program, define the
following items:
v The location of the Tivoli OMEGAMON XE for Mainframe Networks Tivoli
Enterprise Management Server SOAP server endpoint
v At least one Tivoli OMEGAMON XE for Mainframe Networks Tivoli Enterprise
Management Server target
|
|
|
Define these by using the appropriate webmenu statements in the CNMSTWBM
member. For more information about webmenu statements, see the IBM Tivoli
NetView for z/OS Administration Reference.
Chapter 4. Installing and Configuring the Web Application
107
108
Installation: Configuring Additional Components
Chapter 5. Extending the Command Environment
You can add or modify commands and command lists for your installation. The
NetView program procedure language support includes command lists written in
the NetView command list language and the REXX language. You can also write
command processors and installation exits in a high-level language. The high-level
language supported in the NetView environment is the Language Environment®
for z/OS.
If you want information about...
Refer to...
Writing commands and command lists
IBM Tivoli NetView for z/OS Customization
Guide
Using Language Processor (REXX) Environments in the NetView
Environment
Before the TSO/E language processor can process an exec, a language processor
environment must exist. A language processor environment is the environment in
which a REXX exec runs. The following information describes how the NetView
program uses these REXX environments and highlights issues to consider when
estimating the number of language processor environments needed for your
configuration.
The NetView program provides a number of parts that contain REXX source code.
In addition, certain NetView components such as the MultiSystem Manager and
AON consist of parts that contain compiled REXX code. All of the compiled REXX
parts shipped with the NetView program have been compiled with the
ALTERNATE option. If you access the REXX runtime library from the NetView
environment, compiled REXX programs are run in compiled mode. Otherwise, the
REXX alternate library is used and compiled REXX programs run in interpreted
mode.
The NetView program also contains several parts that make use of the Data REXX
function. Use the Data REXX function to include REXX instructions and functions
in data files.
When a REXX command list is run in the NetView program, the REXX interpreter
sets up a language processor environment for the NetView program. When the
command list ends, this unique environment can be held for reuse by the same
task. The NetView program retains these REXX environments to improve REXX
environment initialization performance. As a result, it is very important to have a
sufficient number of REXX environments available to the NetView program. If
more blocks are required than are available, the NetView program issues the
CNM416I REXX environment initialization error message.
Before running any REXX command lists in a z/OS environment, determine the
number of concurrent REXX command lists that are usually active for a task. The
NetView program retains up to three REXX environments and their associated
storage until the operator logs off or the number of REXX environments retained is
changed by the DEFAULTS or OVERRIDE command. Additionally, the NetView
© Copyright IBM Corp. 2001, 2009
109
program always retains one REXX environment per task for Data REXX use. The
MultiSystem Manager and AON utilize REXX command lists extensively.
The IRXANCHR table is a Time Sharing Option Extensions (TSO/E) table used to
reserve storage for REXX environments. Both the NetView program and TSO/E
refer to this table when allocating storage for each REXX environment that is
activated.
When calculating the maximum number of language processor environments that
the system can initialize in the NetView address space, consider the following
items:
v Two entries in the REXX IRXANCHR table are required for each non-nested
NetView or REXX command list to run. If a REXX command list is called from
another REXX command list, a new environment is not required. The nested
command list uses the environment of the primary command list.
v A recommended default number of REXX environment entries in IRXANCHR
for the NetView program is twice the maximum number of command lists that
can be scheduled to run concurrently under all NetView tasks plus two
additional entries for each concurrent active NetView task, including the main
task.
The maximum number of environments the system can initialize in an address
space depends on the maximum number of entries defined in the environment
table, IRXANCHR, and on the kind of environments being initialized. To change
the number of environment table entries, you can use the IRXTSMPE sample that
TSO/E provides in SYS1.SAMPLIB or you can create your own IRXANCHR load
module. The IRXTSMPE sample is a System Modification Program/Extended
(SMP/E) user modification (USERMOD) to change the number of language
processor environments in an address space. The prolog of IRXTSMPE has
instructions for using the sample job. The SMP/E code that is included in the
IRXTSMPE sample handles the installation of the load module.
Storage associated with each REXX environment can increase depending on the
needs of the REXX command lists. Because each REXX command list can have
different storage needs, REXX environments can grow to meet the needs of the
most demanding REXX command list.
The following REXX environment values are set during NetView initialization:
v REXXENV. The number of inactive environments to be retained for each
operator
v REXXSLMT. The amount of storage (in 1K increments) that a REXX environment
can accumulate before being stopped after its current use is completed
v REXXSTOR. The amount of storage (in 1K increments) to be acquired by REXX
environment initialization processing
Tuning the number of REXX environments and controlling how these
environments are maintained within the NetView program improves performance,
particularly if you are running MultiSystem Manager and AON. To limit REXX
environment growth, use the DEFAULTS or OVERRIDE commands to modify the
REXXENV, REXXSLMT and REXXSTOR values.
You can also override these default values by adding a DEFAULTS statement in
the CNMSTUSR or CxxSTGEN member. For example, the system default value for
|
|
110
Installation: Configuring Additional Components
|
|
|
REXXSLMT is 250. To change this value to 300, add the following statement. For
information about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started.
DEFAULTS.REXXSLMT=300
The values of REXXENV, REXXSLMT and REXXSTOR do not apply to Data REXX
environments. When Data REXX environments are built, the Data REXX
environments are limited to one per task, and these environments last for the life
of the task no matter how much storage they need.
If you want information about...
Refer to...
Estimating and tuning the number of REXX
environments
“Estimating REXX Environments”
Enhancing REXX Performance
IBM Tivoli NetView for z/OS Tuning Guide
Introduction to the REXX Language
IBM Tivoli NetView for z/OS Programming:
REXX and the NetView Command List Language
Language Processor Environments
(IRXANCHR)
TSO/E Library
DEFAULTS and OVERRIDE commands and
REXXENV, REXXSLMT and REXXSTOR
IBM Tivoli NetView for z/OS Command
Reference Volume 1 (A-N) and the IBM Tivoli
NetView for z/OS Tuning Guide
Estimating REXX Environments
The IRXANCHR table is a Time Sharing Option Extensions (TSO/E) table used to
reserve storage for REXX environments. Both the NetView program and TSO/E
refer to this table when allocating storage for each REXX environment that is
activated. If IRXANCHR is set to accommodate 24 REXX environments, when the
25th TSO/E REXX EXEC or NetView REXX command list that needs a REXX
environment tries to start, it does not run because it cannot access a REXX
environment. When this happens and you are running a NetView REXX command
list, you receive message CNM416I with a return code of 20 and a reason code of
24. This error message means you have run out of REXX environments.
To ensure that your system has enough REXX environments for all processing,
change the value for IRXANCHR. Because the NetView administrator is often not
the same person as the TSO/E administrator, maintain a separate copy of the
IRXANCHR table for NetView use.
Follow these steps to estimate the number of NetView REXX environments you
require in IRXANCHR:
1. Obtain a copy of the IRXANCHR table from your TSO/E administrator. This
table is stored in the TSOANCH member of the SYS1.SAMPLIB data set.
2. Determine the maximum number of REXX environments that a human
NetView operator might need at one time. Not all operators need to use the
same number of REXX environments.
3. Multiply the number in the previous step by the maximum number of human
operators that are to use the NetView program at the same time.
4. Determine the total number of automated operator tasks you need to use, and
add that total to the number in the previous step. (This assumes that each
automated task uses only one REXX environment at a time.)
5. To the previous total, increase the number to include new operators you might
add later and for work shifts that occasionally need extra operators.
Chapter 5. Extending the Command Environment
111
6. Determine the maximum number of NetView tasks that might be active at one
time and add this number to the previous total. This number represents the
total number of data REXX environments.
7. Each REXX environment requires two entries in IRXANCHR. Multiply the
total from the previous step by 2 and add one more to that doubled number.
The result is the grand total.
8. Replace the TOTAL setting in the IRXANCHR table header in the TSOANCH
member, which you obtained from the TSO/E administrator, with the grand
total.
9. Change the Assembler DS statement that identifies the amount of storage
needed for the total number of IRXANCHR table entries. Refer to the
instructions in the TSOANCH sample for details.
10. Run the TSOANCH sample job to assemble your updated IRXANCHR load
module.
11. If the load module is not link-edited as part of the TSOANCH job, link-edit
your updated IRXANCHR table in a NetView private library and specify that
library name in a STEPLIB DD statement in the NetView startup procedure.
In addition to adjusting the total number of REXX environments in IRXANCHR,
you can tune the default number of REXX environments that the NetView program
retains for each operator during an operator session. The NetView product ships
with a default setting that retains three REXX environments for each operator
(REXXENV=3). However, this number might have been adjusted on your system. To
see the current setting, issue a LIST DEFAULTS command, and check the
REXXENV setting.
Note: Data REXX environments are independent of the DEFAULTS and
OVERRIDE command settings for REXX. Every active NetView task is
assigned only one REXX environment that is dedicated to data REXX.
If an operator attempts to start four REXX command lists and each command list
needs a REXX environment, the NetView program requests the environments,
regardless of the REXXENV setting. However, when two or more of the REXX
command lists for the operator complete, the NetView program frees only one of
the four REXX environments now assigned to that operator. When REXXENV=3
and three or more REXX environments have been assigned to an operator, the
NetView program keeps three of them active until the operator logs off or until a
reset of the REXXENV value is processed. When the operator logs off, all REXX
environments assigned to that operator are returned to the free pool where they can
be assigned to another operator.
Waiting for a REXX environment to be assigned (rather than using one that is
already retained) is a relatively small performance impact for human operators;
however, the impact can be more significant on automated operator tasks.
Automated tasks, which have the global command priority set to LOW and
REXXENV is set to 1 or greater, do not have to wait for a REXX environment to be
assigned.
Storage Considerations
The storage associated with each REXX environment can grow over time,
depending on the needs of the REXX command lists that use the REXX
environments. Because all REXX command lists do not have the same storage
needs, the REXX environments eventually grow to meet the needs of the most
demanding REXX command list.
112
Installation: Configuring Additional Components
v The storage associated with each REXX environment can grow over time,
depending on the needs of the REXX command lists that use the REXX
environments. Because all REXX command lists do not have the same storage
needs, the REXX environments eventually grow to meet the needs of the most
demanding REXX command list (REXXENV).
v To limit the number of REXX environments required by the NetView program,
and thus reduce the amount of storage required for each task using REXX, use
the NetView DEFAULTS and OVERRIDE commands (REXXSLMT).
Before running REXX command lists in an MVS environment, determine the
amount of storage required to initiate a REXX environment. TSO/E REXX, by
default, gets sufficient storage for an average REXX command list, with about six
levels of nested calls. You can change the amount of storage acquired by using the
DEFAULTS or OVERRIDE commands. REXX command lists that use many REXX
variables or that nest more than six levels increase this storage as needed. Each
REXX command list requires approximately 12K of storage to get started.
Using High-Level Languages with the NetView Program
To use high-level languages with the NetView program:
v Ensure that your Language Environment for z/OS runtime libraries are included
in the link pack area (LPA), the LINKLSTxx, or in CNMPROC (CNMSJ009).
|
|
Note: You can place some or all of the Language Environment for z/OS runtime
library modules in LPALSTxx and remove any Language Environment for
z/OS runtime libraries in the LPALSTxx from the STEPLIB of your
NetView start procedure (CNMPROC) to improve performance of the
NetView program. For more information, see the z/OS Language
Environment library and the IBM Tivoli NetView for z/OS Tuning Guide.
v Ensure that all of the runtime libraries are APF-authorized.
v CNMPROC (CNMSJ009) includes an example of the runtime libraries in the
STEPLIB of your start procedure. For example:
//*
DD
DSN=CEE.SCEERUN,DISP=SHR
If you are not running with the Language Environment for z/OS runtime
libraries in PLPA or LINKLSTxx, uncomment the DD statement that applies to
you and make any necessary changes. These changes take effect the next time
the NetView program is started.
You can also define I/O data set members for use with PL/I and C programs.
The following examples are included in CNMPROC (CNMSJ009).
//*PINFILE
//*POUTFILE
//*CINFILE
//*COUTFILE
|
|
|
|
|
|
DD
DD
DD
DD
DSN=USER.HLL.INFILE,DISP=SHR
DSN=USER.HLL.OUTFILE,DISP=SHR
DSN=USER.HLL.INFILE,DISP=SHR
DSN=USER.HLL.OUTFILE,DISP=SHR
Uncomment any that you want to use. Ensure that you have allocated the data
sets before you start the NetView program.
v The CNMSTYLE member contains definitions that request the building of
preinitialized language environments. Review the defaults and make any
necessary changes in the CNMSTUSR or CxxSTGEN member. For information
about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started. If you are not using either the PL/I or C
program, set the REGENVS value to 0.
The following list shows the defaults in the CNMSTYLE member for PL/I:
Chapter 5. Extending the Command Environment
113
HLLENV.IBMADPLI.REGENVS=2
HLLENV.IBMADPLI.CRITENVS=0
HLLENV.IBMADPLI.DEFAULT=NOTPREINIT
HLLENV.IBMADPLI.PSTACK=131072
HLLENV.IBMADPLI.PHEAP=131072
//
//
//
//
//
# of preinitialized environments
max # of env for enabled progs
eligible programs PREINIT?
run time stack size
run time heap size
The following list shows the defaults in the CNMSTYLE member for C:
|
HLLENV.IBMADC.REGENVS=2
HLLENV.IBMADC.CRITENVS=0
HLLENV.IBMADC.DEFAULT=NOTPREINIT
HLLENV.IBMADC.PSTACK=131072
HLLENV.IBMADC.PHEAP=131072
//
//
//
//
//
# of preinitialized environments
max # of env for enabled progs
eligible programs PREINIT?
run time stack size
run time heap size
If you want information about...
Refer to...
The PL/I sample command processors
IBM Tivoli NetView for z/OS Programming:
PL/I and C
Using high-level languages with NetView
IBM Tivoli NetView for z/OS Programming:
PL/I and C
Defining Commands and Command Lists
CNMCMD is a member of DSIPARM that is used to define commands. To modify
existing command definitions:
1. Copy the existing command definition from CNMCMD or its included
members to CNMCMDU.
2. Modify the copied CMDDEF statements in CNMCMDU.
Add any new command definitions to CNMCMDU.
Subsequent sections explain how to accomplish the following tasks:
v Add command processors.
v Specify a command type.
v Load a command module only when that command is run.
v Create synonyms for command keywords.
v Create a command or command list synonym.
v Issue a system or subsystem command from the NetView program.
Adding Command Processors
Add a CMDDEF statement to define the command verb for each command
processor that you have written. Store your command processors in STEPLIB.
CMDDEF definition statements are located in CNMCMD. To avoid migration
problems, place your command definition statements in CNMCMD %INCLUDE
member CNMCMDU. In the NetView program, the LIST command is defined
with the following statement:
CMDDEF.LIST.MOD=DSISHP
Where:
LIST
Is the name of the command.
DSISHP
Is the name of the module that contains the code to run the
command.
Notes:
1. When you are defining a user-written command processor, be sure to specify a
unique module name on the MOD operand. Do not use a name that the system
114
Installation: Configuring Additional Components
might recognize as a command, because the NetView program attempts to
process that command instead of the user-written command processor.
2. Ensure that all CMDDEF statements begin in column 1.
3. Make all changes in uppercase.
You can use the ADDCMD command to dynamically add a command without
restarting the NetView program. The command definition remains in effect until
you restart the NetView program.
If you want information about...
Refer to...
The CMDDEF definition statement
IBM Tivoli NetView for z/OS Administration
Reference
Command authorization
IBM Tivoli NetView for z/OS Security Reference
Specifying a Command Type
The TYPE operand has the following options:
R
A regular command
I
An immediate command
B
Both regular and immediate commands
D
A data services command
RD
A regular or data services command
P
A PIPE command stage
RP
A regular or PIPE command stage
BP
A regular, immediate, or PIPE command stage
H
A high priority command
Notes:
1. A command list is always TYPE=R.
2. Do not change the command type for any CMDDEF statement that is supplied
on the distribution tape.
3. When you add a CMDDEF statement for a user-written command processor,
TYPE=R is assumed unless you specify otherwise.
In the samples, the RESET command is defined in the following way:
CMDDEF.RESET.MOD=DSIRSP
CMDDEF.RESET.TYPE=B
CMDDEF.RESET.CMDSYN=CANCEL
Note: If a module is intended to be used as a RESUME, LOGOFF, or ABEND
routine, the first CMDDEF statement defining this module in CNMCMD
must not be TYPE=I.
Loading a Command Module Only When That Command Is
Run
Command modules that you supply do not have to be in active storage all the
time the NetView program is running. To save storage, you might want to delay
loading the command module for a rarely used command until that command is
run. If you use a command often, however, you probably want to load the
command module at initialization and keep it resident in active storage to save
processing time required to load the module.
You designate whether a command module is kept resident in active storage by
coding the RES operand of the CMDDEF statement. If you do not specify a RES
Chapter 5. Extending the Command Environment
115
operand, the command module is kept resident in active storage. If you want to
load a command module when the command is run rather than at initialization,
specify RES=N.
If you change command processors for testing purposes, you might want to specify
RES=N on the CMDDEF statement. Specify RES=N to change a command
processor without having to stop and restart the NetView program.
Before specifying RES=N for user command processors defined with CMDDEF
definitions, verify that they do not depend on being loaded at the same location
from one command call to the next.
Commands require RES=Y under the following conditions:
v If the code cannot be entered again or cannot be refreshed
v If an internal entry address is used as a system or VTAM exit address
v If the code is self-modifying
v If the control blocks are queued from modules
v If an address within a module is used as a parameter to another task
Notes:
1. Do not change RES=Y to RES=N, or change from the default RES value to
RES=N, on any CMDDEF statement that is supplied as a part of the NetView
samples. If you change the residency (RES) of these modules, you can receive
NetView abends. If a conflict in residencies exists between two CMDDEF
statements, the default of RES=Y is chosen, and the module is resident.
2. If you specify RES=N for a command that is coded with TYPE=I or TYPE=B
(the immediate commands), the command is still processed as if you coded
RES=Y.
Creating a Synonym for a Command or Command List
To create a synonym for a command or a command list, use the CMDSYN
definition statement. Operators can then enter either the original command name
or the new command name.
To create a command synonym:
1. Add a CMDSYN definition on the CMDDEF statement. If you use multiple
CMDSYN statements, specify *PREV* to continue the list of synonyms.
Otherwise the synonyms replace synonyms defined in previous statements. For
example:
CMDDEF.command.CMDSYN=*PREV*,synonym1,synonym2
2. Inform the operators of the new command name.
Be careful not to use a name that is a VTAM command, another NetView
command or command synonym, or a command in an application program that
runs with the NetView program. Also, do not modify the command names on the
CMDDEF statements that are supplied by the NetView product in CNMCMD.
Some of these command processors depend on the name of the command to
process correctly.
|
|
In the sample, you can create a synonym for the AUTOWRAP command in the
following way:
CMDDEF.AUTOWRAP.CMDSYN=A
Now, the AUTOWRAP command is also named A. You can request AUTOWRAP
by entering A.
116
Installation: Configuring Additional Components
Note: You can use the ADDCMD command to add or replace synonyms without
having to recycle NetView.
Some CMDDEF statements in the samples already have CMDSYNs assigned to
them, such as the following NetView command list:
CMDDEF.CNME0001.CMDSYN=ACQ
If you assign additional names, use *PREV* as one of the values on the CMDSYN
statement. Otherwise, the new value replaces the previous value. When you assign
a CMDSYN, ensure that the name is unique.
If you want information about...
Refer to...
Operands of the CMDDEF definition
statement
IBM Tivoli NetView for z/OS Administration
Reference
ADDCMD command
IBM Tivoli NetView for z/OS Command
Reference Volume 1 (A-N)
Suppressing Command Echoes
Echoes of commands that you type on the command line are sent to the screen
when you press the ENTER key. Use command echo suppression to prevent echoes
of certain commands from displaying on the screen. Suppression is useful when
command echoes interfere with displays.
|
|
Note: Do not change the ECHO operand on any CMDDEF statements that are
supplied by the NetView product. The NetView program uses this option to
perform screen control when moving between components. If you change
this operand, you can receive unexpected results at the terminal.
In the samples, the CLEAR command is defined with the following statements:
CMDDEF.CLEAR.MOD=DSICKP
CMDDEF.CLEAR.TYPE=H
CMDDEF.CLEAR.ECHO=N
CMDDEF.CLEAR.SEC=BY
Where:
ECHO=N
Specifies that the command is not echoed to the screen.
Note that the commands that are issued from command lists follow the
&CONTROL statement rules.
If you want information about...
Refer to...
The &CONTROL statement rules
IBM Tivoli NetView for z/OS Programming:
REXX and the NetView Command List Language
Creating Command Keyword Synonyms
Using synonyms for a command keyword can make the network operator’s job
easier. To create a command keyword synonym, code a parameter synonym
(PARMSYN) on the CMDDEF statement for each keyword for which you are
creating a synonym.
For example, you can add the following PARMSYN statements to alter keywords
of the BGNSESS CMDDEF statement:
Chapter 5. Extending the Command Environment
117
CMDDEF.BGNSESS.PARMSYN.OPCTL=OP
CMDDEF.BGNSESS.PARMSYN.APPLID=TO
CMDDEF.BGNSESS.PARMSYN.SRCLU=FROM
CMDDEF.BGNSESS.PARMSYN.SESSID=ID
CMDDEF.BGNSESS.PARMSYN.LOGMODE=LOG
Where:
OPCTL
OP
Is the keyword for which you are creating a synonym.
Is the new name for the keyword.
Now instead of entering the following command:
BGNSESS
OPCTL,APPLID=IMS1,SRCLU=TAF01O00,SESSID=SESS1,LOGMODE=S3270
your operator can type this command to get the same results:
BGNSESS
OP,TO=IMS1,FROM=TAF01O00,ID=SESS1,LOG=S3270
Issuing System and Subsystem Commands from the NetView Console
Place CMDDEF statements in CNMCMDU so that you can enter nonconflicting
MVS system and subsystem commands from a NetView console without prefixing
the command with MVS. Each CMDDEF statement represents one MVS subsystem
command name that does not conflict with currently defined network command
names.
For examples of CMDDEF statements that define MVS, JES2, and JES3 commands,
refer to members CNMS6401, CNMS6402, and CNMS6403 in
NETVIEW.V5R4M0.CNMSAMP. Comments are provided in these members to help
you select any you might want to use.
The following format is the format for the CMDDEF statements:
CMDDEF.name.MOD=CNMCMJC
Where name is any MVS or subsystem command name.
118
Installation: Configuring Additional Components
Chapter 6. Configuring Optional NetView Services
|
You can include the following optional NetView services and functions:
v Management services (MS) transport function
v High performance transport
v Save/restore task for timers, global variables, PNA registrations, and focal points
v DB2® subsystem access
v TSO command server
v UNIX command server
v NetView for z/OS discovery library adapter (DLA)
v NetView Web Services Gateway
Defining Management Services Transport
|
|
The management services (MS) transport function enables applications that are
supplied by the NetView product or written by users to send data and to receive
data from partner applications. Operations management and focal point
applications are some examples of applications that use the MS transport.
|
The CNMSTYLE member contains the following task statement for the MS
Transport function:
TASK.DSI6DST.INIT=Yes
DSI6INIT is the MS transport initialization sample and contains the following
statement:
DSTINIT FUNCT=OTHER,XITDI=DSI6IDM
CNMCMSYS contains the following CMDDEF statements for the MS transport:
CMDDEF.REGISTER.MOD=DSI6REGP
CMDDEF.REGISTER.RES=N
CMDDEF.DSI6DSCP.MOD=DSI6DSCP
CMDDEF.DSI6DSCP.TYPE=D
CMDDEF.DSI6DSCP.PARSE=N
CMDDEF.DSI6LOGM.MOD=DSI6LOGM
CMDDEF.DSI6LOGM.TYPE=D
CMDDEF.DSIOSRCP.MOD=DSIOSRCP
CMDDEF.DSIOSRCP.TYPE=RD
CMDDEF.DSIOSRCP.PARSE=N
CMDDEF.DSIOARCP.MOD=DSIOARCP
CMDDEF.DSIOARCP.TYPE=RD
CMDDEF.DSIOARCP.PARSE=N
CMDDEF.DSIOARCP.SEC=BY
CMDDEF.DSIOURCP.MOD=DSIOURCP
CMDDEF.DSIOURCP.TYPE=D
CMDDEF.DSIOURCP.PARSE=N
CMDDEF.DSIOURCP.SEC=BY
CMDDEF.DSIOLGFP.MOD=DSIOLGFP
CMDDEF.DSIOLGFP.TYPE=RD
CMDDEF.DSIOLGFP.PARSE=N
CMDDEF.DSIOLGFP.SEC=BY
CMDDEF.DSI6SNDP.MOD=DSI6SNDP
CMDDEF.DSI6SNDP.TYPE=RD
CMDDEF.DSI6SNDP.PARSE=N
CMDDEF.DSI6SNDP.RES=N
CMDDEF.DSI6SNDP.SEC=BY
© Copyright IBM Corp. 2001, 2009
119
Defining High Performance Transport
Use the NetView high performance transport to send and receive large amounts of
data using LU 6.2 communications.
The CNMSTYLE member contains the following task statement for the high
performance transport function:
|
TASK.DSIHPDST.INIT=Y
DSIHINIT is the high performance transport initialization member. To establish
nonpersistent conversations, uncomment the following statement in DSIHINIT:
*
PARTNER NETID=NETA,NAME=CNM02,PERSIST=NO
Where:
NETID
Specifies the network ID of your system. If you specify the network ID as
an asterisk (*), the network ID defaults to the one determined by VTAM
based on the partner name of the remote node.
NAME
Specifies the name of the partner (logical unit or control point name) with
which you are initiating a conversation.
PERSIST
Specifies whether all conversations between this NetView system and the
remote node are persistent. If you do not specify the PERSIST keyword,
the default is YES, meaning conversations are persistent.
Note: You do not have to code this statement at the remote node to use the high
performance transport.
The DSIHPDST task uses the following CMDDEF statements in DSIPARM member
CNMCMSYS:
CMDDEF.DSI6DSCP.MOD=DSI6DSCP
CMDDEF.DSI6DSCP.TYPE=D
CMDDEF.DSI6DSCP.PARSE=N
CMDDEF.DSI6LOGM.MOD=DSI6LOGM
CMDDEF.DSI6LOGM.TYPE=D
The following CMDDEF statements in DSIPARM member CNMCMSYS are used
by DSIHSNDS and CNMHSMU:
CMDDEF.DSIOLGFP.MOD=DSIOLGFP
CMDDEF.DSIOLGFP.TYPE=RD
CMDDEF.DSIOLGFP.PARSE=N
CMDDEF.DSIOLGFP.SEC=BY
CMDDEF.DSI6SNDP.MOD=DSI6SNDP
CMDDEF.DSI6SNDP.TYPE=RD
CMDDEF.DSI6SNDP.PARSE=N
CMDDEF.DSI6SNDP.RES=N
CMDDEF.DSI6SNDP.SEC=BY
Defining the Save/Restore Function
Timers, global variables, programmable network access (PNA) registrations, and
focal point information can be saved to VSAM and restored when the NetView
program is restarted.
The CNMSTYLE member contains the following task statement:
|
120
Installation: Configuring Additional Components
TASK.DSISVRT.INIT=Y
The AAUDCPEX command definition statement in the CNMCMSYS member is
used for the save/restore function:
CMDDEF.AAUDCPEX.MOD=AAUDCPEX
CMDDEF.AAUDCPEX.TYPE=D
CMDDEF.AAUDCPEX.PARSE=N
CMDDEF.AAUDCPEX.SEC=BY
The database for the save/restore function is defined using the CNMSJ004 job with
input member CNMSI101.
|
To define security passwords for the save/restore function:
1. Stop the DSISVRT task.
2. Modify the definition statements in CNMSI101 that define the save/restore
database, changing them to include the specification of VSAM cluster
passwords. Rerun job CNMSJ004 using these modified statements to delete and
redefine the save/restore database.
3. Update the CNMSTPWD member in DSIPARM to include the password that
you specified when redefining the save/restore database. The following
example shows the PWD statement that defines the password for the
save/restore database:
PWD.DSISVRT.P = password
where:
password
Is the 1- to 8-character password for the database.
4. Restart the DSISVRT task.
Defining DB2 Subsystem Access
To use the DB2 program libraries, uncomment the following statement in sample
CNMSJ009:
//*
DD
DSN=DSN510.SDSNLOAD,DISP=SHR
CNMSJSQL is a sample installation job that defines the plan for the NetView SQL
stage to DB2. In the sample job, the name of the library on the SYSUT2 JCL
statement must match the name specified in the BIND statement in the second step
of the job. For example, the sample uses USER2.DBRMLIB. Modify this value to
suit your system:
//SYSUT2 DD DSN=USER2.DBRMLIB(DSISQLDO),DISP=SHR
Change the IBMUSER value in the sample to identify the NetView program that is
using SQL. Do not change the values for DSISQLnn, DSISQLDO, and DSISQLDP.
Usually the NetView plan name is DSISQLnn, where nn is changed because of
service or future releases. The CNMSJSQL sample is reshipped whenever a change
to the DSISQLDO program causes the plan to be incompatible.
BIND PACKAGE(DSISQL04) MEM(DSISQLDO) ACT(REP) ISOLATION(CS) LIB('USER2.DBRMLIB') OWNER(USER2)
BIND PACKAGE(DSISQL14) MEM(DSISQLDP) ACT(REP) ISOLATION(CS) LIB('USER2.DBRMLIB') OWNER(USER2)
BIND PLAN(DSISQL04) ACT(REP)
PKLIST(DB2L01.DSISQL04.DSISQLDO,DB2L01.DSISQL14.DSISQLDP)
ISOLATION(CS) OWNER(USER2)
-
To access SQL databases using the SQL and SQLCODE pipe stages, the DSIDB2MT
task is used to define the default DB2 subsystem. This task connects the NetView
Chapter 6. Configuring Optional NetView Services
121
program to a specific DB2 subsystem so that any task in the NetView address
space has access to that DB2. You can start the task using the NetView START
command:
START TASK=DSIDB2MT,MOD=DSIDB2MT,MEM=DSIDB2DF,PRI=1
You can also start the SQL task automatically during NetView initialization. To do
this, update the following task statement in the CNMSTUSR or CxxSTGEN
member (change INIT=N to INIT=Y). For information about changing CNMSTYLE
statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
|
|
|
TASK.DSIDB2MT.INIT=Y
Other DB2 subsystems can be specified by an operand on the SQL pipe stage. The
SQL pipe stage can access DB2 subsystems regardless of whether DSIDB2MT is
started, provided the subsystem name is specified on the SQL stage.
The DSIDB2DF member of DSIPARM defines the DB2 subsystem to which the
NetView program connects. It uses one definition statement:
SUBSYSTEM=DB2
Starting the TSO Command Server
You can start the TSO command server from the NetView program by issuing the
START TSOSERV command. The TSO command server starts either as a submitted
job or as an MVS started task, depending upon the setting of the STRTSERV
parameter of the DEFAULTS command.
If multiple versions of the TSO command server JCL are required, the optional
MEM parameter can be specified on the START TSOSERV command. The default
member name is CNMSJTSO for submitted jobs and CNMSSTSO for MVS started
tasks.
If the TSO command server is started as a submitted job, ensure that the sample
job CNMSJTSO is contained in a DSIPARM data set. If the TSO server is started as
a started task, ensure that the sample job CNMSSTSO is copied into a data set
defined in the IEFJOBS or IEFPDSI concatenation of master JCL, for example,
SYS1.PROCLIB. This is required because CNMSSTSO contains a job statement.
Also ensure that the sample MVS START command CNMSTSOS is contained in a
DSIPARM data set. For more information about specifying whether the TSO server
runs as a submitted job or as a started task, refer to the online help for the
DEFAULTS STRTSERV command.
Before you start a TSO command server, you can customize the samples that are
provided with the NetView program to fit your environment. If the SCNMLNKN
data set is not defined as part of the LNKLST concatenation, you must include a
STEPLIB DD statement for it in the TSO command server JCL. When a START
TSOSERV command is issued, the NetView program issues an MVS START
command (if DEFAULTS STRTSERV is set to STRTPROC) or submits a job (if
DEFAULTS STRTSERV is set to SBMTJOB). For a started task, member CNMSTSOS
contains the MVS START command that is used to start the procedure or job
specified in the START TSOSERV command. For a submitted job, the member
specified on the MEM keyword in the START TSOSERV command is submitted as
an MVS job.
|
|
|
|
Member CNMSTSOS or the member containing the submitted JCL, for example,
CNMSJTSO, can contain specific variables for which the NetView program
122
Installation: Configuring Additional Components
performs substitutions before the task is started or the job is submitted. These
variables have names that begin with an ampersand (&) followed by lowercase
letters and end with a period (.). You can specify any of these substitution
variables to customize how your TSO server is started. The following list describes
these variables:
&sprcnm.
The member name containing the JCL that is to be started or submitted.
This value is the value of the MEM keyword on the START TSOSERV
command
v For a started task, if MEM is not specified, CNMSSTSO is used. This
variable is specified in sample CNMSTSOS as the procedure or job to
start.
v For a submitted job, if MEM is not specified, CNMSJTSO is used. This
variable is not specified in sample CNMSJTSO because it is the same as
the sample name.
&jobname.
The name to be used on the JOB statement on a submitted job. This value
is dynamically built and is equivalent to the &ppiname. value, starting at
the second character.
v For a started task, this variable is not specified in sample CNMSTSOS
because it does not apply to the MVS START command.
v For a submitted job, this variable is specified in sample CNMSJTSO as
the name on the JOB statement.
&userid.
The TSO user ID under whose authority the started task or submitted job
runs. To easily identify which user ID the task or job is running for, the
JOBNAME (for start) or the step name (for submit) specifies this name. The
value is the value on the TSOSERV keyword on the START TSOSERV
command.
v For a started task, this variable is specified in sample CNMSTSOS as the
value for the JOBNAME keyword on the MVS START command.
v For a submitted job, this variable is specified in sample CNMSJTSO for
the values for the USER keyword on the JOB statement and for the step
name on the EXEC statement.
&ppiname.
The receiver name used for communication between the server and the
NetView program across the PPI. This value is dynamically built and is
used to communicate to the PPI receiver.
v For a started task, this variable is specified in sample CNMSTSOS on the
PPINAME keyword on the MS START command. Sample CNMSSTSO
uses this value as the first parameter passed to the CNMETSO program.
v For a submitted job, this variable is specified in sample CNMSJTSO as
the first parameter passed to the CNMETSO program.
&key. A random number used for correlation between the TSO server and the
command requester. The value is used in the following ways:
v For a started task, this variable is specified in sample CNMSTSOS on the
KEY keyword on the MVS START command. Sample CNMSSTSO uses
this value as the second parameter passed to the CNMETSO program.
v For a submitted job, this variable is specified in sample CNMSJTSO as
the second parameter passed to the CNMETSO program.
Chapter 6. Configuring Optional NetView Services
123
If you want information about...
Refer to...
START TSOSERV command
IBM Tivoli NetView for z/OS Command
Reference Volume 1 (A-N) for NCCF START
TSO server defaults
IBM Tivoli NetView for z/OS Command
Reference Volume 1 (A-N) for DEFAULTS
STRTSERV
Starting the UNIX Command Server
The UNIX command server enables UNIX commands to be entered from the
NetView command line and returns the output of these commands to the NetView
console. For more information, see “Defining the UNIX Command Server” on page
208.
Enabling the NetView for z/OS Discovery Library Adapter
A NetView for z/OS discovery library adapter (DLA) can collect mainframe and
distributed TCP/IP data from the NetView for z/OS RODM data cache. Using FTP,
the DLA sends the data as a discovery library book to an IBM Tivoli Change and
Configuration Management Database (IBM Tivoli CCMDB) file server or to another
data store for which a discovery library reader exists. These discovery library
books contain data about the resource instances and their relationships known to
the system.
You can run this DLA on one centralized NetView for z/OS installation, which can
collect data in the RODM data cache from one or more MultiSystem Manager IP
agents. If your enterprise distributes its TCP/IP topology information across
multiple NetView for z/OS installations, each of which maintains a RODM data
cache, the DLA can be deployed at any or all of those NetView for z/OS
installations.
The following software must be running for this DLA to run successfully:
v Tivoli NetView Version 7.15 or later on a distributed platform, running with the
TCP/IP Discovery service and the MultiSystem Manager IP agent
v TSO command server. This is started if it is configured. See “Using a TSO
Command Server” on page 126.
Configuring the Discovery Library Adapter
The NetView for z/OS DLA dynamically creates and deletes two files and modifies
one file. The DLA must be configured to enable this behavior. All configuration
options are specified in the CNMSTYLE member and are described in the IBM
Tivoli NetView for z/OS Administration Reference. Descriptions in these files indicate
which configuration parameters are required and which are optional. Each
parameter is prefixed by the characters DLA. Make any changes in the CNMSTUSR
or CxxSTGEN member. For information about changing CNMSTYLE statements,
see IBM Tivoli NetView for z/OS Installation: Getting Started.
|
|
|
|
The DLA does not require any command line parameters.
These items outline the requirements:
v The file that is specified by the DLA.xml_filename parameter in the CNMSTYLE
member (default value NETVIEW.V5R4USER.DLA.CNMDLA) is created. This parameter
is required and must point to a sequential dataset to which the DLA can write.
|
|
124
Installation: Configuring Additional Components
|
|
|
|
This sequential file, which exists only while the DLA is running, buffers the
XML discovery library book before it is transmitted to the IBM Tivoli CCMDB
file server using FTP. After the DLA completes, this file is deleted.
v The file specified by the DLA.ftp_log_filename parameter in the CNMSTYLE
member (default value NETVIEW.V5R4USER.DLA.FTPSOUT) is created. This
parameter is required and must point to a sequential dataset to which the DLA
can write. This file buffers log information from the FTP file transmission. This
sequential file exists only while the DLA is running.
v The CNMSTATE file, which is installed by SMP/E, is used by the DLA to store
information about the time stamp and status of the discovery library books
transferred to the IBM Tivoli CCMDB file server. The CNMSTATE file is a
sequential dataset with a default location of NETVIEW.V5R4USER.DLA.CNMSTATE.
The DLA.statefile parameter in the CNMSTYLE member contains the location
of this required file.
You can configure the DLA either while the NetView for z/OS program is stopped
or before it is restarted. If required or optional configuration parameters are
changed in the CNMSTYLE member after the NetView for z/OS program is
started, use the following NetView command to process the changed parameters:
RESTYLE DLA
|
|
|
|
A NetView for z/OS CHRON task for the DLA adapter is predefined to run on the
AUTO2 task each Monday at 2:15 AM. Ensure that this is appropriate for your
system. This parameter is initialized in the CNMSTUSR or CxxSTGEN member
using the auxInitCmd.DLAAUTO statement and can be changed there. By default,
the CHRON task is not set; you must uncomment it to set it. For information
about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started.
If you uncomment the CHRON statement, or change the schedule after the
NetView for z/OS program is restarted, the RESTYLE DLA command does not
pick up the CHRON change. You can initiate or change a CHRON timer without
restarting the NetView for z/OS program by entering the TIMER command at the
NetView for z/OS command line and using the Timer Management window.
Confirming the NetView for z/OS and Tivoli NetView Setup
Proper setup of the Tivoli NetView and NetView for z/OS MSM IP functions can
be confirmed by either of the following methods:
v Display the contents of a TCP/IP internetHost resource at the NetView
management console. Running the NetView for z/OS DLA does not require
running either the NetView management console on a workstation or its
prerequisite, Graphic Monitor Facility Host Services, on a z/OS system.
However, most installations that have RODM installed also take advantage of
the NetView management console function.
v Display the contents of a TCP/IP internetHost resource in RODMVIEW:
1. Enter the command RODMVIEW at the NetView command line.
2. Connect to RODM.
3. Perform a "simple query" for
SystemView class name = internetHost
4. Provide the object name:
Object name = *
Chapter 6. Configuring Optional NetView Services
125
5. You can confirm that the Tivoli NetView and NetView for z/OS MSM IP
functions are installed and running if results are returned; that is, if you do
not receive an EKGV9314E No Match found. message.
Accessing the IBM Tivoli CCMDB File Server
You can confirm that the target IBM Tivoli CCMDB file server is running by
issuing a PING command to the fully qualified IP host name of the target IBM
Tivoli CCMDB file server. IBM Tivoli CCMDB does not need to be running for the
DLA to create and transfer a discovery library book.
Note: For testing purposes, the DLA transfers files to any FTP server for which
you have access authority.
You can confirm access to the FTP service on the target file server by successfully
sending a file to the server using FTP:
1. Open an FTP session to the target FTP server from the TSO command line on
the source z/OS system with the following commands:
=6
FTP IP_hostname
2. Use the same target FTP server user ID and password that you specify in
“Setting the IBM Tivoli CCMDB File Server Password” on page 127.
3. Change the source directory as needed, for example:
lcd ..
lcd user.init
4. Change the target directory as needed, for example:
cd ..
cd /tmp/dla/
5. Send an existing file with this command:
PUT myfile
Using a TSO Command Server
The DLA uses a TSO command server to launch the FTP client to transfer the
discovery library book to the IBM Tivoli CCMDB file server. If a TSO command
server is already running for functions other than this DLA, this DLA uses the TSO
command server and leaves it running after the DLA completes. If a TSO
command server is configured but not running, the DLA starts the TSO command
server and uses it to transfer the discovery library book to the IBM Tivoli CCMDB
file server; the DLA then stops the TSO command server.
To configure a TSO command server, if one is not already defined, see “Starting
the TSO Command Server” on page 122 for information about CNMSJTSO.
Consider the following items that pertain to the TSO command server CNMSJTSO:
v Ensure that the following line in CNMSJTSO specifies the dataset where member
CNMFTP is located:
//SYSPROC DD DSN=netview.v5r4m0.cnmclst,DISP=(SHR)
v Ensure that the TSO command server has an adequate region size. The default
region size is not adequate for this DLA. A region size of 0M (allocated
dynamically) is sufficient for most installations. Define it in the following way:
//&userid. EXEC PGM=IKJEFT01,REGION=0M,TIME=NOLIMIT,
PARM='CNMETSO,&ppiname.,&key.,NODEBUG'
v Check the default setting of the strtsrv environment variable by issuing this
command:
126
Installation: Configuring Additional Components
LIST defaults
Review the output. If you do not see the setting STRTSERV: sbmtJob, you can set
the STRTSERV variable by issuing the following command from the NetView for
z/OS program:
DEFAULTS STRTSERV=sbmtJob
Setting the IBM Tivoli CCMDB File Server Password
|
|
|
|
The DLA uses the NetView for z/OS capability of securing passwords by storing
them in the CNMSTPWD member. To ensure that CNMDLAR can successfully
connect to the IBM Tivoli CCMDB file server using FTP, uncomment PWD.DLA.P in
the CNMSTPWD member, and assign to it the password for the user ID that is
specified in theDLA.ftp_uid parameter in the CNMSTYLE member. These two
parameters define the user ID and password that are used to open an FTP session
to the IBM Tivoli CCMDB file server. They must be defined before CNMDLAR is
run. The authority to view and change the CNMSTPWD member might be
restricted to a limited class of operators.
Running the Discovery Library Adapter
The NetView for z/OS DLA can be run in either of two ways:
v Enter this command at the NetView for z/OS command line:
CNMDLAR
|
|
v To run it automatically at a regularly scheduled time, uncomment the
auxInitCmd.DLAAUTO statement in the CNMSTUSR or CxxSTGEN member
that processes the NetView for z/OS CHRON timer. For additional information
about this statement, see “Configuring the Discovery Library Adapter” on page
124. For information about changing CNMSTYLE statements, see IBM Tivoli
NetView for z/OS Installation: Getting Started.
|
|
|
When this DLA runs, results are recorded in the NetView for z/OS log
(NETLOGA). More detailed results can be written to the NETLOG by setting the
optional DLA.debug statement in the CNMSTUSR or CxxSTGEN member. For
information about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started.
|
After the DLA completes it delivers a discovery library book to the target IBM
Tivoli CCMDB file server. As specified by IBM Tivoli CCMDB conventions, the
book name includes a time stamp and identifies the NetView for z/OS program,
and the host on which it resides, as the management software system, for example:
NETVZ53.hostname.2007-7-16T20-42-45Z.xml
This discovery library book is not retained on the z/OS system.
If this DLA runs more than once, the output file name contains the term refresh,
as shown in the following example:
NETVZ53.hostname.2007-7-18T18-26-09Z.refresh.xml
To force the IBM Tivoli CCMDB Bulk Loader to do a create operation, erase the
last time stamp value in file CNMSTATE, as shown in the following example:
LAST_SUCCESSFUL_TRANSMISSION =
The DLA can take from 30 seconds to 15 minutes to run, depending on the number
of TCP/IP-managed resources discovered.
Chapter 6. Configuring Optional NetView Services
127
|
Configuring NetView Web Services Gateway
|
|
|
|
Web Services Gateway provides you with an industry-standard open interface into
the NetView program to issue commands and receive responses. It uses SOAP over
HTTP or HTTPS as the transport mechanism to drive the request and to receive a
reply.
|
|
|
|
|
These tasks are required to set up Web Services Gateway:
v “Configuring the NetView program”
v “Preparing the MVS System” on page 130
v “Preparing the Web Resources Files” on page 130
v “Verifying NetView Web Services” on page 131
||
If you want information about...
Refer to...
|
|
Using NetView Web Services Gateway
IBM Tivoli NetView for z/OS Application
Programmer’s Guide
|
|
|
CNMSTYLE statements
IBM Tivoli NetView for z/OS Administration
Reference
Configuring the NetView program
|
|
|
|
Configuring the NetView program includes the following steps:
v “Configuring the CNMSTYLE Member”
v “Updating the NetView Startup Procedure” on page 129
|
v “Configuring Security” on page 130
|
|
|
|
Configuring the CNMSTYLE Member
To enable the Web Services Gateway function, copy the TOWER statement from
the CNMSTYLE member to the CNMSTUSR or CxxSTGEN member and remove
the asterisk (*) before the NVSOA component.
|
|
|
|
The AUTONVSP autotask is used to attach the SOASERV command. To change the
autotask name, modify the function.autotask statement in CNMSTYLE member
CNMSTUSR or CxxSTGEN:
|
|
|
|
|
|
Review the CNMSTYLE statements in Table 18 and make any necessary updates in
the CNMSTUSR or CxxSTGEN member. The srvrname is set to SOASRVR1 in the
CNMSTYLE member. To change the server name, modify the NVSP.srvrname
statements to specify the name of the Web Services server. You can start additional
servers on different listening ports by varying the srvrname on the CNMSTYLE
statements.
|
Table 18. CNMSTYLE statements
|
CNMSTYLE statement
Function
|
|
NVSP.srvrname.CIPHERSP
Specifies the SSL V3 cipher specifications that are used for
the SSL V3 protocols.
|
|
|
NVSP.srvrname.CLNTAUTH
Specifies whether the SSL server application accepts a
connection from a client that has requested client
authentication but has not supplied an X.509 certificate.
|
|
NVSP.srvrname.KEYRING
Specifies the location of the PKI private keys and
certificates for SSL.
(NVSOA)function.autotask.NVSOAPTSK = AUTONVSP
128
Installation: Configuring Additional Components
|
Table 18. CNMSTYLE statements (continued)
|
CNMSTYLE statement
Function
|
NVSP.srvrname.LABEL
Specifies the label of the key database or the key ring.
|
|
|
|
NVSP.srvrname.NUMTHRDS
Specifies the number of threads to be created to service
incoming and outgoing IP connections. The minimum value
is 1. If values greater than 2 147 483 647 are specified, these
are set to the default value of 2 147 483 647.
|
NVSP.srvrname.PASSTHRU
Specifies whether to bypass client certificate validation.
|
NVSP.srvrname.PASSWORD
Specifies the password for the key database or the key ring.
|
|
NVSP.srvrname.PDS
Specifies the location where server Web resources files are
located.
|
|
|
NVSP.srvrname.PORT
Specifies the port on which the server is listening for
connection requests. The minimum value is 0. Values
greater than 2 147 483 647 default to 2 147 483 647.
|
|
NVSP.srvrname.SECURE
Specifies whether the transport is secured with SSL
encryption.
|
|
|
NVSP.srvrname.SESTOUT
Specifies the number of seconds until an SSL V3 session
identifier expires. The minimum value is 0. Values greater
than 2 147 483 647 default to 2 147 483 647.
|
NVSP.srvrname.STH
Specifies the name of the key database password stash file.
|
NVSP.srvrname.TRC
Specifies the initial trace levels.
|
|
NVSP.srvrname.USERCACH
Specifies whether to use the user cache to cache SSL
connections.
|
|
|
|
NVSP.srvrname.WAIT
Specifies the number of seconds to wait for a command
response. The minimum value is 0. Values greater than
2 147 483 647 default to 2 147 483 647.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Updating the NetView Startup Procedure
|
|
Alternatively you can add these libraries to the LPALSTxx member. For more
information, see IBM Tivoli NetView for z/OS Installation: Getting Started.
Uncomment the following XML toolkit and GSKit libraries in the CNMPROC
(CNMSJ009) member:
//*
//*
//*
//*
//*
//*
//*
//*
//*
//*
//*
//*
//*
//*
//*
//*
//*
//*
IF YOU ARE STARTING THE NETVIEW WEB SERVICES SERVER THEN
YOU WILL NEED ACCESS TO BOTH IBM XML TOOLKIT AND GSKIT RUN
TIME LIBRARIES
- IF YOU HAVE THESE LIBRARIES ON YOUR SYSTEM
BUT THEY ARE NOT ACCESSIBLE FROM THE PLPA OR LINKLST,
THEN YOU MUST UNCOMMENT THE LINES BELOW.
WHEN YOU UNCOMMENT EITHER OF THE LINES BELOW, MAKE SURE
THAT THE DSN ACTUALLY MATCHES THE NAME ON YOUR SYSTEM.
IN ADDITION, MAKE SURE THAT THE DATA SET IS APF-AUTHORIZED.
FOR THE LINES BELOW, THE FOLLOWING JCL SYMBOLICS ARE ASSUMED:
QIXM='IXM.V1R8M0', ** IBM XML TOOLKIT RUNTIME LIB.
QGSK='SYS1',
** IBM GSK TOOLKIT RUNTIME LIB.
DD
DD
DSN=&QGSK..SIEALNKE,DISP=SHR
DSN=&QIXM..SIXMLOD1,DISP=SHR
Chapter 6. Configuring Optional NetView Services
129
|
|
|
|
|
Configuring Security
|
|
|
|
Commands are run under the authority of the operator ID specified on the SOAP
request. SSL encryption is used to secure the transport to the server. For
information about configuring security, see IBM Tivoli NetView for z/OS Security
Reference.
The Web Services server uses basic NetView operator ID and password or
password phrase authentication for commands. Verify that the operator ID and
password or password phrase that you plan to use are defined in the RACF
product or in the DSIOPF member.
Preparing the MVS System
|
|
|
|
|
|
|
Member PROGxx contains the names of program libraries that you want the
system to concatenate to SYS1.LINKLIB and libraries that you want to define as
authorized with the Authorized Program Facility (APF). Add the XML toolkit and
GSKit run time libraries to the PROGxx PARMLIB member:
|
|
The &QGSK and &AIXM variables must match the high-level qualifiers that are
defined in the CNMPROC (CNMSJ009) sample.
APF ADD DSNAME(&QGSK..SIEALNKE)
APF ADD DSNAME(&QIXM..SIXMLOD1)
VOLUME(xxxxxxxx)
VOLUME(xxxxxxxx)
Preparing the Web Resources Files
|
|
|
|
The Web resources files that are used by the Web Services server are located in the
following directory:
|
|
See Table 19 to update the files for your environment. The WSDL files
automatically generate a proxy-client connection.
|
Table 19. Web Services Gateway files
|
File name
Purpose
Modifications
|
|
|
|
|
|
znvsoatx.htm
Text-based Web Services
client. This file works
with Microsoft Internet
Explorer version 7 or
later or Mozilla 2.0.014
or later.
Update URLs for your environment. Locate
the <SELECT> tag and modify the
<OPTION>your.web.services.server</OPTION>
tag.
|
|
|
|
|
|
znvsoa.htm
Graphic version of the
Web Services client. This
file works only with
Microsoft Internet
Explorer version 7 or
later.
Update URLs for your environment. Locate
the <SELECT> tag and modify the
<OPTION>your.web.services.server</OPTION>
tag.
|
|
|
znvwsdl.wsdl
Provides Web services
definitions for different
output formats.
Update the soap:address location for your
environment. You can do this by locating the
<soap:address location= > tag.
|
|
|
znvwsdl1.wsdl
Provides Web services
definitions for different
output formats.
Update the soap:address location for your
environment. You can do this by locating the
<soap:address location= > tag.
|
|
|
|
znvwsdl2.wsdl
Provides Web services
definitions for different
output formats.
Update the soap:address location for your
environment. You can do this by locating the
<soap:address location= > tag.
/usr/lpp/netview/v5r4/www/
130
Installation: Configuring Additional Components
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Static and dynamic proxy SOAP clients, and also socket proxy client samples, are
shipped in the following directory:
/usr/lpp/v5r4/samples
Verifying NetView Web Services
Follow these steps to use the generic SOAP client to verify the output of the
command that you sent:
1. Start Internet Explorer version 7 or later or Firefox 2.0.0.14 or later.
2. Enable the Access data sources across domains option in the security settings
for the domain in which your server is located. Enter one of the following
addresses for the SOAP client:
http://netviewhost:port/znvsoatx.htm
https://netviewhost:port/znvsoatx.htm
The SOAP client HTML page is displayed.
3. In the NetView for z/OS Generic SOAP Client panel, enter the Endpoint, for
example:
http://netviewhost:port/znvsoa
4. Enter the SOAP method:
DoCmd
|
|
|
|
|
After you enter the method, the other fields are completed automatically.
5. Modify the tags or the text in the Edit Payload (XML) area as shown in the
following example:
|
|
|
|
|
where sysadmin and passwd define the NetView operator ID and password or
password phrase under which to run the command, and nvcmd is the NetView
command to run.
6. Click Make SOAP Request. The output of the request is displayed in the
SOAP Response Payload field.
|
|
|
If necessary, you can use the SOACTL command to enable tracing. The trace
entries are written to the network log. For more information about the SOACTL
command, see IBM Tivoli NetView for z/OS Command Reference Volume 1 (A-N).
<Name>sysadmin</Name><Password>passwd</Password>
<NVCMD><cmd><![CDATA[nvcmd]]</cmd></NVCMD>
Chapter 6. Configuring Optional NetView Services
131
132
Installation: Configuring Additional Components
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Chapter 7. Enabling IP Management
This chapter includes the following topics:
v “IP Enablement Overview”
v “Setting Required Statements for IP Management” on page 134
v “Setting Policy Statements” on page 135
v “Enabling TCP/IP Services” on page 135
v “Enabling TCP/IP Connection and Packet Trace Data Collection” on page 136
v “Enabling DVIPA Management” on page 139
v “Enabling the Discovery Manager” on page 143
v “Defining Critical IP Port Monitoring” on page 146
v “Enabling IP Functions with the IPMGT Tower” on page 146
v “Setting Up TCP/IP Support for the AON IP Functions” on page 146
IP Enablement Overview
|
|
|
|
|
To enable IP management in the NetView program, you must examine and, if
appropriate, either set or update the following statements; for more information,
see “Setting Required Statements for IP Management” on page 134.
v The TCPname statement in the CNMSTUSR or CxxSTGEN member
v The IPv6Env environment statement in the CNMSTUSR or CxxSTGEN member
|
|
v The MAXPROCSYS and MAXPROCUSER statements in the BPXPRMxx member
in the SYS1.PARMLIB data set
|
|
To enable additional IP functions in the NetView program, take the following
actions, as appropriate for your environment:
v To set policy statements for IP management, see “Setting Policy Statements” on
page 135.
v To collect and view packet trace data using the IPTRACE or PKTS command or
to view inactive connection data using the NetView workspaces in the Tivoli
Enterprise Portal, see “Enabling TCP/IP Connection and Packet Trace Data
Collection” on page 136.
v To configure sysplex management, see Chapter 8, “Configuring NetView Sysplex
Management,” on page 157. For information about managing sysplexes, see IBM
Tivoli NetView for z/OS IP Management.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
v To enable dynamic virtual IP address (DVIPA) support, see “Enabling DVIPA
Management” on page 139. For information about managing DVIPAs, see IBM
Tivoli NetView for z/OS IP Management.
v To enable the discovery manager, see “Enabling the Discovery Manager” on
page 143. For information about managing resources that are discovered by the
discovery manager, see IBM Tivoli NetView for z/OS IP Management.
v To define monitoring for critical ports, see “Defining Critical IP Port Monitoring”
on page 146.
v To enable IP functions with the IPMGT tower, see “Enabling IP Functions with
the IPMGT Tower” on page 146.
v To enable the RSH, REXEC, and syslog (IPLOG) daemons, see “Enabling TCP/IP
Services” on page 135.
v To use the UNIX System Services RESOLVER_CONFIG environment variable for
resolving the TCP/IP configuration data, see “TCP/IP Considerations” on page
201.
© Copyright IBM Corp. 2001, 2009
133
v To install the MultiSystem Manager IBM Tivoli Network Manager agent for
discovering IP resources, see the instructions in the msm_nm_ip_readme_en.html
file on the NetView for z/OS installation DVD. For more information about
configuring MultiSystem Manager agents, see IBM Tivoli NetView for
z/OS Installation: Configuring Graphical Components. For information about the
MultiSystem Manager IBM Tivoli Network Manager agent, see IBM Tivoli
NetView for z/OS IP Management.
v To install the MultiSystem Manager IP agent for discovering IP resources, see the
instructions in the msmip.me file on the NetView for z/OS installation DVD. For
more information about configuring MultiSystem Manager agents, see IBM Tivoli
NetView for z/OS Installation: Configuring Graphical Components. For information
about the MultiSystem Manager IP agent, see IBM Tivoli NetView for z/OS IP
Management.
v To set up the TCP/IP support for AON IP functions, see “Setting Up TCP/IP
Support for the AON IP Functions” on page 146.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Setting Required Statements for IP Management
To enable IP management in the NetView program, you must examine and either
set or update the following statements. For statements in the CNMSTUSR or
CxxSTGEN member, see the information about using and changing CNMSTYLE
statements in IBM Tivoli NetView for z/OS Installation: Getting Started.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
v By default, the NetView program supports both IPv4 and IPv6 addressing. To
limit the NetView program to one addressing family, use the IPv6Env
environment statement in the CNMSTUSR or CxxSTGEN member. For
information about the IPv6Env statement, see the IBM Tivoli NetView for
z/OS Administration Reference.
|
|
|
|
|
|
|
|
|
|
v Examine the settings for the MAXPROCSYS and MAXPROCUSER statements in
the BPXPRMxx member in the SYS1.PARMLIB data set. The MAXPROCSYS
statement specifies the maximum number of processes that can be active at the
same time. The MAXPROCUSER statement specifies the maximum number of
processes with a single UID that are allowed to be active at the same time. The
number of TCP/IP-related processes that are spawned as a result of NetView
commands can exceed the system-supplied defaults for these UNIX System
Services settings. These limits might need to be increased. The settings can be
temporarily increased by using the SETOMVS command and remain in effect
until the next IPL.
v Set the TCPname statement in the CNMSTUSR or CxxSTGEN member to the
TCP/IP job name. You can use a system symbolic (&CNMTCPN) in the
SYS1.PARMLIB data set to set the value of the TCPname statement. MVS needs
to be restarted after the system symbolic is defined.
During initialization, the NetView program uses the value of the TCPname
statement to set the DEFAULTS.TCPNAME value that is used by these NetView
TCP/IP services. You can override the value set in the CNMSTYLE member by
using the DEFAULTS command to change DEFAULTS.TCPNAME prior to
starting (or restarting) the tasks, or you can override the value in the
initialization members for the tasks. The DEFAULTS command can be issued by
an operator or by a CLIST. This default applies to the NetView program, and
cannot be overridden for a particular operator.
134
Installation: Configuring Additional Components
|
Setting Policy Statements
|
|
|
The following table lists the policy statements for IP management, in alphabetical
order by statement, and the member in which each is coded. For more information
about these statements, see the IBM Tivoli NetView for z/OS Administration Reference.
|
Table 20. IP Management Policy Definitions
|
Description
Statement
Member Where Coded
|
Active monitoring
ACTMON
CNMIPMGT
|
|
Connection monitoring threshold
definition
IPCONN
CNMIPMGT
|
Host definition
IPHOST
CNMIPMGT
|
Interface definition
IPINFC
CNMIPMGT
|
Nameserver definition
IPNAMESERV
CNMIPMGT
|
Socket definition
IPPORT
CNMIPMGT
|
Router definition
IPROUTER
CNMIPMGT
|
Telnet server definition
IPTELNET
CNMIPMGT
|
TN3270 server definition
IPTN3270
CNMIPMGT
|
|
Stack definition
TCP390
CNMPOLCY
|
|
|
|
|
|
|
|
Consider the following definitions for TCP390 statements:
v To enable commands that use SNMP, such as the IPTRACE and NVSNMP
commands, define the community name.
v To receive DVIPA traps, define the same community name in the NetView
program that you have configured in z/OS Communications Server for SNMP
support. For more information about setting the community name for SNMP
support, see the z/OS Communications Server Configuration Reference.
v Define stacks that the discovery manager does not find dynamically.
|
|
Note: To set community names for non-stack resources that use SNMP, use the
CNMSCM member.
|
Enabling TCP/IP Services
The NetView program supplies several TCP/IP services that are provided as server
and client functions. Server and client functions are available for the REXEC, RSH,
and syslog services. The TN3270 service is only available as a client function. The
REXEC and RSH services provide remote command processing support. The syslog
service provides remote logging. A NetView operator can use the TN3270 service
to establish a 3270 Telnet session with a Telnet server.
|
|
To enable the server function of these TCP/IP services, complete the following
steps:
1. You can also specify the TCP/IP parameters for each task that is associated
with these TCP/IP services in the CNMSTUSR or CxxSTGEN member. When
the task is restarted with the RESTYLE command, the values that are specified
in the CNMSTYLE member are used by the TCP/IP service.
Table 21 on page 136 shows the task and initialization statements for each
TCP/IP service that is available as a server function.
Chapter 7. Enabling IP Management
135
Table 21. TCP/IP Services
|
|
Task Initialization
Statements in the
CNMSTYLE Member
TCP/IP Service
NetView Task
REXEC
DSIRXEXC
REXEC.TCPANAME
REXEC.PORT
REXEC.SOCKETS
REXEC.PROTOCOL
RSH
DSIRSH
RSH.TCPANAME
RSH.PORT
RSH.SOCKETS
RSH.PROTOCOL
TCP/IP syslog
DSIIPLOG
IPLOG.TCPANAME
IPLOG.PORT
IPLOG.SOCKETS
2. If you are running the RSH server, place the DSIRHOST sample in DSIPARM
and modify it to meet your security needs. In the following example of this file,
all users on host1 except for user1 and all users on host2 can use RSH to send
commands to the NetView program:
|
|
+host1
+host1 -user1
+host2
3. Ensure that the DSIRXEXC, DSIRSH, and DSIIPLOG tasks are started to
complete the setup for the REXEC, RSH, and syslog servers. These tasks can be
set to start automatically during initialization by changing INIT=N to INIT=Y
in the following task statements in the CNMSTUSR or CxxSTGEN member. For
information about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started.
|
|
|
TASK.DSIIPLOG.INIT=Y
TASK.DSIRSH.INIT=Y
TASK.DSIRXEXC.INIT=Y
No special setup is needed to enable the client function of these TCP/IP services
other than ensuring that the DEFAULTS.TCPNAME value is set correctly. The
client commands (REXEC, RSH, IPLOG, and TN3270) can therefore be issued from
the NetView program without the NetView server tasks being active.
|
Enabling TCP/IP Connection and Packet Trace Data Collection
TCP/IP connection data is collected in two ways in the NetView program:
v Using the TCPCONN START and TCPCONN QUERY commands. This method
requires an autotask that uses a socket interface. Inactive connection data that is
displayed in the NetView workspaces in the Tivoli Enterprise Portal is collected
using this method.
v Using the TCPCONN QUERYACT command. This method uses the EZBNMIFR
interface of z/OS Communications Server. Active connection data that is
displayed in the NetView workspaces in the Tivoli Enterprise Portal and
connection data that is displayed in IPSTAT panels are collected using this
method.
v Review, and if necessary, update the IPMGT tower in the CNMSTUSR or
CxxSTGEN member for the IPTRACE function. For information about changing
CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation: Getting
Started.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
136
Installation: Configuring Additional Components
|
|
|
|
|
Packet trace data is collected using the PKTS START and PKTS QUERY commands.
For each type of packet trace data that is collected, this method requires an
autotask that uses a socket interface. Packet trace data that is displayed in
IPTRACE panels is collected using this method. The IPTRACE packet trace data is
formatted using the FMTPACKT command.
|
|
The rest of this topic describes how to set up connection and packet trace data
collection that requires an autotask and uses the socket interface.
|
|
To use the socket interface to collect Open Systems Adapter (OSA) packet trace
data, you must be running z/OS V1R11 Communications Server or later. In
addition, you must enable the NETMONITOR statement in your TCP/IP profile in
z/OS Communications Server. To do that, add the following statement to your
TCP/IP profile:
>
NETMONITOR TCPCONNSERVICE PKTTRCSERVICE NTATRCSERVICE
Where:
TCPCONNSERVICE
Enables the collection of TCP/IP connection data
|
PKTTRCSERVICE
Enables the collection of IP packet trace data
>
|
NTATRCSERVICE
Enables the collection of OSA packet trace data
If you do not want to collect data from one of these services, remove the
appropriate parameter from the NETMONITOR statement.
For more information, see the z/OS Communications Server IP Configuration Reference.
Especially note the SAF (RACF) requirement that the user ID (in this case
associated with the NetView autotask described in the following text), or address
space, must be permitted access to the relevant resources.
|
|
|
|
|
|
|
|
To configure the collection of TCP/IP connection and packet trace data in the
NetView product, perform the following steps:
v Ensure that the TCP/IP connection management databases have been defined.
The TCP/IP connection management databases are defined using the CNMSJ004
job with input member CNMSI101.
v Review and, if necessary, update the TCPIPCOLLECT tower in the CNMSTUSR
or CxxSTGEN member, along with the appropriate subtowers (TCPCONN for
TCP/IP connection management, PKTS for packet trace management). See the
IBM Tivoli NetView for z/OS Administration Reference for more information. For
information about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started.
v Review and, if necessary, update autotasks to handle the collection of connection
and packet trace data. To do this automatically during NetView startup, use the
function.autotask statements that are shown in Table 22 on page 138, where
stackname is the name of the TCP/IP stack, in the CNMSTUSR or CxxSTGEN
member. For information about changing CNMSTYLE statements, see IBM Tivoli
NetView for z/OS Installation: Getting Started.
Chapter 7. Enabling IP Management
137
|
Table 22. Stack Connection and Packet Trace Data Collector Autotasks
|
|
Autotask
Name
|
AUTOOPKT OSA packet trace data
(TCPIPCOLLECT.OPKT)function.autotask.OPKT.stackname = AUTOOPKT
|
AUTOPKTS Packet trace data
(TCPIPCOLLECT.PKTS)function.autotask.PKTS.stackname = AUTOPKTS
|
|
|
AUTOTCPC Connection data for a
stack
(TCPIPCOLLECT.TCPCONN)function.autotask.TCPCONN.stackname = AUTOTCPC
Collector Autotask
Function
CNMSTYLE Statement
You can also define these autotasks interactively using the TCPCONN DEFINE
and PKTS DEFINE commands. See the online help for more information.
v If you want to start data collection automatically during NetView startup, add
the following statements to the CNMSTUSR or CxxSTGEN member. For
information about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started.
– For connection data:
|
|
|
(TCPIPCOLLECT.TCPCONN)INIT.TCPCONN = Yes
– For packet trace data:
(TCPIPCOLLECT.PKTS)INIT.PKTS = Yes
– For OSA packet trace data:
|
|
(TCPIPCOLLECT.OPKT)INIT.OPKT = Yes
You can also start data collection interactively using the TCPCONN START and
the PKTS START commands. For more information about these commands, see
the online help.
v To stop data collection, use the TCPCONN STOP and PKTS STOP commands.
For more information about these commands, see the online help.
v To define security passwords for the TCP/IP connection management databases:
1. Stop the TCP/IP connection management by using the TCPCONN STOP
command.
|
|
2. Modify the definition statements in CNMSI101 that define the TCP/IP
connection management databases, changing them to include the
specification of VSAM cluster passwords. Rerun the CNMSJ004 job using
these modified statements to delete and redefine the TCP/IP connection
management databases.
3. Update the CNMSTPWD member in DSIPARM to include the passwords that
you specified when redefining the TCP/IP connection management
databases. The following example shows the PWD statements that define the
passwords for the TCP/IP connection management databases, where
p_password is the 1- to 8-character password for the primary database and
s_password is the 1- to 8-character password for the secondary database:
|
PWD.DSITCONT.P = p_password
PWD.DSITCONT.S = s_password
4. Restart the TCP/IP connection management by using the TCPCONN START
command.
v To enable automatic database maintenance for the TCP/IP connection data
VSAM database, add a corresponding DBINIT command to the CNMSTUSR or
CxxSTGEN member. (See the comments in the TCPCONN section of the
CNMSTYLE member for more information.) For information about changing
CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation: Getting
Started.
v To filter the collection of connection data, add TCPCONN.KEEP and
TCPCONN.DASD statements to the CNMSTUSR or CxxSTGEN member. (See
|
|
|
|
|
|
|
|
138
Installation: Configuring Additional Components
the comments in the TCPCONN section of the CNMSTYLE member for more
information.) For information about changing CNMSTYLE statements, see IBM
Tivoli NetView for z/OS Installation: Getting Started.
|
|
|
Enabling DVIPA Management
Management of dynamic virtual IP addresses (DVIPAs) includes the following
items. By default, all DVIPA management is disabled.
v “DVIPA Data Collection”
v “DVIPA Events”
v “Distributed DVIPA Statistics” on page 142
v “User Interface Configuration for DVIPA Management” on page 142
|
|
|
|
|
|
DVIPA Data Collection
|
To enable DVIPA data collection for a domain, complete the following actions:
v Ensure that the DVIPA tower is uncommented on the TOWER statement in the
CNMSTUSR or CxxSTGEN member. For information about changing
CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation: Getting
Started. Note that enabling the DVIPA tower collects only DVIPA definition and
status information.
v To enable additional DVIPA data collection, ensure that the TOWER.DVIPA
subtowers (DVTAD, DVCONN, and DVROUT) are uncommented.
v If you are running z/OS V1R10 Communications Server or earlier, ensure that
the z/OS Communications Server SNMP agent (OSNMPD) is running.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
v The autotasks in Table 23 are used by the DVIPA subtowers for data collection.
To change the autotask name, modify the function.autotask statement in the
CNMSTUSR or CxxSTGEN member. Also review, and if necessary, update the
autotask name in the DSIOPF member.
|
Table 23. DVIPA Data Collector Autotasks
|
Autotask Name Collector Autotask Function
CNMSTYLE Statement
|
AUTOCT1
DVIPA definition and status
(DVIPA)function.autotask.COLTSK1 = AUTOCT1
|
AUTOCT2
Distributed DVIPA
(DVIPA.DVTAD)function.autotask.COLTSK2 = AUTOCT2
|
AUTOCT3
DVIPA connections
(DVIPA.DVCONN)function.autotask.COLTSK3 = AUTOCT3
|
|
|
AUTOCT4
VIPA routes and distributed DVIPA
connection routing
(DVIPA.DVROUT)function.autotask.COLTSK4 = AUTOCT4
|
|
|
|
|
|
|
Sampling intervals for DVIPA data collection are 1 hour. If you want to modify
these intervals, review the following CNMSTYLE statements and make any
updates in the CNMSTUSR or CxxSTGEN member:
v DVIPA.INTDVTAD
v DVIPA.INTDVCONN
v DVIPA.INTDVDEF
v DVIPA.INTDVROUT
|
|
|
For summary information about enabling data collection and data display for
DVIPAs, see Appendix B, “Data Collection and Display for the NetView User
Interfaces,” on page 239.
|
|
DVIPA Events
To enable DVIPA events automation, complete the following steps:
Chapter 7. Enabling IP Management
139
v Review the following DVIPA event automation samples to determine the events
that you want to monitor:
– CNMSDVCG monitors z/OS Communications Server VIPADYNAMIC TCPIP
profile changes.
– CNMSDVTP monitors z/OS Communications Server DVIPA traps.
– CNMSSMON monitors z/OS Communications Server sysplex monitoring
messages.
|
|
|
|
|
|
|
Remove or comment out the samples that you choose not to use.
|
|
|
|
|
|
|
Note: DVIPA traps and VIPADYNAMIC TCPIP profile changes can be generated
for the same actions.
v The DVIPAUTO autotask is used for DVIPA event automation. To change the
autotask name, modify the function.autotask statement in the CNMSTUSR or
CxxSTGEN member:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DVIPA Traps
(DVIPA)function.autotask.DVIPAUTM = DVIPAUTO
To enable DVIPA traps, complete the following actions:
v Update the z/OS Communications Server snmpd.conf configuration file to send
traps to the NetView program. For information about updating the snmpd.conf
file, see the z/OS Communications Server IP Configuration Reference.
v Enable SNMP by starting the z/OS Communications Server SNMP agent
(OSNMPD). For more information, see the z/OS Communications Server IP
Configuration Reference.
v Configure the SNMP Trap Automation Task Configuration statements from the
CNMSTYLE member in the CNMSTUSR or CxxSTGEN member; for information
about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started.
– Use the same port on which traps are sent (default 162).
– Indicate in these statements the name of the DST task that is to catch the
traps, or manually start this DST task.
Note: If traps are being generated for IBM Tivoli Network Manager through
MultiSystem Manager, use the same DST task name for both IBM
Tivoli Network Manager and the NetView program.
|
|
|
|
|
|
|
The NetView program can then receive the following z/OS Communications
Server DVIPA traps:
v ibmMvsDVIPAStatusChange
v ibmMvsDVIPARemoved
|
|
|
To receive additional z/OS Communications Server DVIPA traps, issue the
following UNIX Systems Services command:
|
|
|
|
|
The following z/OS Communications Server DVIPA traps can then be received:
v ibmMvsDVIPATargetAdded
v ibmMvsDVIPATargetRemoved
v ibmMvsDVIPATargetServerStarted
v ibmMvsDVIPATargetServerEnded
snmp -h host -r 0 -c communityname -v set ibmmvsdvipatrapcontrol.0 \'FC\'h
140
Installation: Configuring Additional Components
DVIPA TCPIP Profile Updates
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To receive z/OS Communications Server VIPADYNAMIC TCPIP profile updates,
configure the following statements:
v Add a NETMON SMFSERVICE PROFILE statement to the z/OS
Communications Server TCPIP profile. For more information about how to
update the TCPIP profile, see the z/OS Communications Server IP Configuration
Reference.
v Review and, if necessary, update an autotask in the CNMSTYLE member for
each TCPIP stack that is to collect z/OS Communications Server
VIPADYNAMIC TCPIP profile updates for the NetView program. Do this by
adding the following statement to your CNMSTUSR or CxxSTGEN member,
where stackname is the name of the TCPIP stack, and taskname is the name of the
autotask that collects TCPIP profile updates. For information about changing
CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation: Getting
Started.
|
|
|
|
By default, the NetView program uses autotask AUTOTCPS to collect TCPIP
profile updates from the TCPIP stack referred to by the &CNMTCPN system
symbolic. For information about changing CNMSTYLE statements, see IBM
Tivoli NetView for z/OS Installation: Getting Started.
function.autotask.TCPSM.stackname=AUTOTCPS
|
Notes:
|
|
|
|
|
|
|
|
1. The DISCOVERY tower does processing to receive TCPIP profile updates. If
you disable the DISCOVERY tower but want to receive TCPIP profile updates,
issue the following internal command:
TCPSM START TCPNAME=tcpproc
2. This function requires z/OS V1R11 Communications Server or later. For more
information about the z/OS Communications Server TCP/IP stack profile
network management interface, see the z/OS Communications Server IP
Programmer’s Guide and Reference.
|
|
|
|
|
|
|
|
Sysplex Monitoring Messages
|
|
|
|
When SYSPLEXMONITOR RECOVERY is specified, the CNMSSMON sample
processes only the EZZ9675E and EZZ9676E messages as events. When SYSPLEX
MONITOR NORECOVERY is specified, the CNMSSMON sample processes all
other messages as events. For more information, see the CNMSSMON sample.
|
|
|
|
|
|
|
DVIPA Event Delay Timers
To receive sysplex monitoring messages, modify the z/OS Communications Server
TCPIP profile to include the SYSPLEXMONITOR parameter on the
GLOBALCONFIG statement. When the SYSPLEXMONITOR parameter is specified
and a problem occurs, z/OS Communications Server issues action messages. When
the problem is resolved, z/OS Communications Server issues a Delete Operator
Message (DOM). The NetView program can automate on both the messages and
the DOMs to start rediscovery.
DVIPA events are used to keep DVIPA information current in the NetView
product. The following event delay timers are built into the DVIPA event
processing to ensure that DVIPA information is not discovered for each DVIPA
event, which can cause performance problems:
v DVIPA.Event.Delay
v DVIPA.Mast.Disc.Delay
Chapter 7. Enabling IP Management
141
|
|
|
|
|
|
|
DVIPA data collection intervals default to one hour. If you are using DVIPA events,
you might want to increase the DVIPA data collection intervals by changing the
following CNMSTYLE statements:
v DVIPA.INTDVDEF
v DVIPA.INTDVTAD
v DVIPA.INTDVCONN
v DVIPA.INTDVROUT
|
|
For more information about using DVIPA with a master NetView program, see
Chapter 8, “Configuring NetView Sysplex Management,” on page 157.
Distributed DVIPA Statistics
|
Distributed DVIPA statistics are kept each time data collection is run for the
DVIPA.DVTAD subtower. To keep distributed DVIPA statistics and review the
statistics, complete the following actions:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
v Run the CNMSJ002 sample job to allocate the primary (CNMDVIPP) and
secondary (CNMDVIPS) sequential data sets where the data is to be written.
v Ensure that the CNMDVIPP and CNMDVIPS DD statements are defined in your
NetView startup procedure. For more information, see the CNMSJ009 sample
job.
v Make sure that the DVTAD subtower is uncommented in the TOWER.DVIPA
CNMSTYLE statement.
v Make sure that the Init.DVIPASTATS CNMSTYLE statement is set to Y to start
the logging of distributed DVIPA statistics at NetView initialization. You can also
use the DVIPALOG command to dynamically start and stop logging of
distributed DVIPA statistics.
v The DVIPSTAT autotask is used to collect distributed DVIPA statistics and to
write the records to a data set. To change the autotask name, modify the
function.autotask statement in the CNMSTUSR or CxxSTGEN member:
(DVIPA)function.autotask.DVIPSTAT = DVIPSTAT
v Review, and if necessary, update the following CNMSTYLE statements to set
filters for the distributed DVIPAs for which statistics are recorded:
– DVIPA.STATS.DVIPA
– DVIPA.STATS.PORT
– DVIPA.STATS.TCPNAME.z
v Review and, if necessary, update the following CNMSTYLE statements that
specify the number of records to write to the corresponding data sets:
– DVIPA.STATS.Pri.MAXR (Primary data set)
– DVIPA.STATS.Sec.MAXR (Secondary data set)
One record is written for each distributed DVIPA target for each data collection,
based on the specified filters.
When the record count is reached, the data set starts logging records to the other
data set. Messages are issued when the primary (CNM482I) and secondary
(CNM483I) data sets become active. For the format of the record written to the
data set, see IBM Tivoli NetView for z/OS IP Management. You can use the
CNMSDVST sample to format the records.
|
|
|
|
|
|
|
User Interface Configuration for DVIPA Management
|
You can manage DVIPAs from the NetView for z/OS Enterprise Management
Agent, the 3270 interface, and the NetView Web application. No configuration is
required for the 3270 interface.
|
|
142
Installation: Configuring Additional Components
|
Configuring the NetView for z/OS Enterprise Management Agent
The NetView for z/OS Enterprise Management Agent provides DVIPA
management functions from the Tivoli Enterprise Portal.
|
|
|
Before you can use the DVIPA management functions, the DVIPA data collection
must be enabled and the DVIPA subtowers under the TEMA tower must also be
enabled.
For more information, see IBM Tivoli NetView for z/OS Installation: Configuring the
Tivoli NetView for z/OS Enterprise Management Agent.
|
Configuring the NetView Web Application
The NetView Web application provides DVIPA management functions. For more
information about the NetView Web application, see “Installing the NetView Web
Application” on page 104.
|
|
|
|
The AUTDVIPA autotask is used to collect DVIPA definition and status data for the
NetView Web application. To change the autotask name, modify the
function.autotask statement in the CNMSTUSR or CxxSTGEN member:
|
Also review, and if necessary, update the autotask name in the DSIOPF member.
|
|
|
|
Update the TCP390 statement in the CNMPOLCY member by adding a
DVIPADAT=Y parameter to each stack for which you intend to manage DVIPA
data. For more information about the DVIPADAT keyword, see the TCP390
statement in the IBM Tivoli NetView for z/OS Administration Reference.
|
|
|
The polling interval for DVIPA data is initially set to 1 hour but can be changed by
modifying the COMMON.CNMSTYLE.DVIPAINTVL statement in the CNMSTUSR
or CxxSTGEN member.
(DVIPA)function.autotask.DVIPA = AUTDVIPA
You can limit the amount of DVIPA data that is displayed at the Web application
in the following ways:
v By specifying filters when requesting DVIPA data in the NetView Web
application. When requesting DVIPA status, you can set filters for TCP name,
z/OS image name, DVIPA, and origin. When requesting DVIPA connection
information, you can set filters for the application (APPL) name, logical unit
(LU) name, remote IP address, and remote port.
|
|
|
|
|
|
|
|
|
|
|
v By customizing the COMMON.CNMSTYLE.DVIPAMAX statement in the
CNMSTUSR or CxxSTGEN member. The default value is to display 256 virtual
IP addresses at the Web browser.
Enabling the Discovery Manager
In NetView V5R4, the discovery manager expands the functionality of the Sysplex
IP Stack Manager by discovering additional sysplex and System z® resources.
Discovery manager data can be viewed in 3270 sessions, the NetView management
console, and the Tivoli Enterprise Portal by using the NetView for z/OS Enterprise
Management Agent. Not all data can be seen in all interfaces.
v “Discovery Manager Data Collection” on page 144
v “Multiple NetView Programs on a Single z/OS Image” on page 145
v “User Interface Configuration for Discovery Manager” on page 145
Chapter 7. Enabling IP Management
143
Discovery Manager Data Collection
|
|
|
Data collection by the discovery manager uses a combination of sampling and
message automation.
|
|
|
|
|
|
|
|
|
|
|
By default, the discovery manager is enabled with the DISCOVERY tower in the
CNMSTYLE member. This provides for data collection of the following kinds of
resources:
v Sysplex
v Coupling facility
v z/OS image
v TCP/IP stack
v NetView application
v Central processor complex (CPC)
v Channel subsystem identifier
v Logical partition (LPAR)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To enable additional discovery manager data collection, complete the following
actions:
v Ensure that the DISCOVERY tower is uncommented on the TOWER statement in
the CNMSTUSR or CxxSTGEN member. For information about changing
CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation: Getting
Started.
v To use SNMP to discover data, set DISCOVERY.SNMP to YES in the
CNMSTUSR or CxxSTGEN member.
v To enable additional discovery manager data collection, ensure that statements
for the TOWER.DISCOVERY and TOWER.DISCOVERY.INTERFACES subtowers
are uncommented. To see IP interface or Telnet server and port information,
uncomment the statements for the appropriate TOWER.DISCOVERY subtowers.
To see Open Systems Adapter (OSA) and HiperSockets™ adapter information,
uncomment the appropriate statements for TOWER.DISCOVERY.INTERFACES
subtowers.
v If you enable the DISCOVERY.INTERFACES subtower, ensure that the z/OS
Communications Server SNMP agent (OSNMPD) is running.
v If you enable the DISCOVERY.INTERFACES.OSA subtower, ensure that the OSA
SNMP subagent (IOBSNMP) is running.
v If you enable the DISCOVERY.INTERFACES.HIPERSOCKETS subtower, ensure
that you are running z/OS V1R11 Communications Server or later.
v The autotasks that are shown in Table 24 are used by the DISCOVERY tower and
subtowers for data collection. To change an autotask name, modify the
function.autotask statement in the CNMSTUSR or CxxSTGEN member; for
information about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started. Also review and, if necessary, update the
autotask name in the DSIOPF member.
|
Table 24. Discovery Manager Autotasks
|
Autotask Name Collector Autotask Function
CNMSTYLE Statement
|
AUTOAON
DISCOVERY tower resources
function.autotask.Policy = AUTOAON
|
|
AUTOCT5
IP interfaces, including OSA and
HiperSockets adapters
(DISCOVERY.INTERFACES)function.autotask.COLTSK5 =
AUTOCT5
|
|
AUTOCT6
Telnet servers and Telnet server ports
(DISCOVERY.TELNET)function.autotask.COLTSK6 =
AUTOCT6
|
|
AUTOCT7
NetView applications
(DISCOVERY)function.autotask.COLTSK7 = AUTOCT7
144
Installation: Configuring Additional Components
|
|
|
|
|
|
|
Sampling intervals are used for IP interfaces (1 hour), Telnet servers and ports (1
hour), and NetView applications (5 minutes). If you want to modify these intervals,
review the following CNMSTYLE statements and make any updates in the
CNMSTUSR or CxxSTGEN member:
v DISCOVERY.INTINTERFACE
v DISCOVERY.INTTELNET
v DISCOVERY.INTAPPL
|
|
|
|
Note: If you are using the NetView for z/OS Enterprise Management Agent, and
you have enabled the TEMA.HEALTH subtower, you might want to set the
DISCOVERY.INTAPPL and NACMD.INTHEALTH intervals to the same
value.
|
|
|
|
Message automation is used to update information when some discovery manager
resources start and stop. Review the CNMSEPTL automation sample member for
these events. The CNMSEPTL member is included when the DISCOVERY tower is
enabled.
|
|
|
For summary information about enabling data collection and data display for
discovery manager resources, see Appendix B, “Data Collection and Display for the
NetView User Interfaces,” on page 239.
|
Multiple NetView Programs on a Single z/OS Image
|
|
|
|
|
If you are running multiple NetView programs on a single z/OS image, you
should either turn off the DISCOVERY tower completely or specify
DISCOVERY.NetViewOnly=YES in the CNMSTUSR or CxxSTGEN member on the
secondary NetView program. For information about changing CNMSTYLE
statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
|
|
|
If DISCOVERY.NetViewOnly=YES is specified, you can collect minimal information
without extra CPU utilization and without the display of duplicate data in the 3270
interface and Tivoli Enterprise Portal at the master NetView program.
|
|
|
|
|
For example, if NetView programs CNM01 and CNM02 are running on the SYS1
z/OS image, the DISCOVERY tower is enabled, and
DISCOVERY.NetViewOnly=NO is set for both NetView programs, 2 rows are
displayed for a single TCP/IP stack on SYS1 in response to a CNMSSTAC
DOMAIN=ALL command issued from the master NetView program.
|
User Interface Configuration for Discovery Manager
|
|
|
You can manage resources that are discovered using the discovery manager from
the NetView management console, the NetView for z/OS Enterprise Management
Agent, and the 3270 interface. No configuration is required for the 3270 interface.
|
|
|
|
|
Using the NetView Management Console
|
|
|
|
Using the Tivoli NetView for z/OS Enterprise Management Agent
You can view sysplex and System z view topology from the NetView management
console. For more information about viewing this topology, see IBM Tivoli NetView
for z/OS IP Management and IBM Tivoli NetView for z/OS User’s Guide: NetView
Management Console.
The NetView for z/OS Enterprise Management Agent provides TCP/IP stack,
Telnet server and port, Open Systems Adapter (OSA), HiperSockets adapter, and
NetView application information from the Tivoli Enterprise Portal.
Chapter 7. Enabling IP Management
145
Before you can use the discovery manager functions, the data collection towers and
subtowers and the TEMA subtowers must be enabled. For more information about
enabling these functions, see IBM Tivoli NetView for z/OS Installation: Configuring the
Tivoli NetView for z/OS Enterprise Management Agent.
|
|
|
|
Defining Critical IP Port Monitoring
|
|
|
The NETSTAT command displays all resources that are currently active. However,
the NETSTAT command can sometimes indicate that a resource is active when the
port for that resource refuses a connection. Use the TESTPORT command to check
a port that looks active but might be refusing connections because it is inactive.
Such ports are known as hung listeners.
|
|
|
|
|
|
|
The TESTPORT command provides additional function for monitoring critical
ports. To define ports that are to be monitored by the TESTPORT command and
the intervals for monitoring them, use the COMMON.IPPORTMON.IPADD,
COMMON.IPPORTMON.INTVL, and COMMON.IPPORTMON.PORTNUM
statements in the CNMSTUSR or CxxSTGEN member. For more information about
these COMMON.IPPORTMON statements, see the IBM Tivoli NetView for
z/OS Administration Reference. For information about changing CNMSTYLE
statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
For additional information about the TESTPORT command, see the online help.
|
Enabling IP Functions with the IPMGT Tower
|
|
|
|
|
|
|
Many IP-related functions that were previously implemented as part of the
NetView Automated Operations Network (AON) component are now implemented
as base NetView services. These functions, which are referred to as the AON IP
functions, no longer require AON enablement and configuration. Instead, they can
be enabled by using the IPMGT tower. However, AON IP functions that are
already enabled using the AON TCP subtower do not need to be reconfigured. The
AON TCP subtower and the IPMGT towers are mutually exclusive.
|
|
|
|
|
|
To enable the IPMAN command for active monitoring of IP resources, use the
IPMGT ACTMON subtower statement in the CNMSTUSR or CxxSTGEN member.
Also, add statements to the CNMIPMGT member for the resources that are to be
monitored; for a list of these statements, see “Setting Policy Statements” on page
135. For information about using CNMSTYLE and tower statements, see IBM Tivoli
NetView for z/OS Installation: Getting Started.
|
|
|
|
To enable automated responses to intrusions detected by the use of z/OS
Communications Server Intrusion Detection Services (IDS), use the IPMGT IDS
subtower statement in the CNMSTUSR or CxxSTGEN member. For more
information about IDS, see “Enabling Intrusion Detection Services” on page 154.
|
|
|
|
|
The following IP functions are also available with the IPMGT tower:
v PING panel
v TRACERTE panel
v NVSNMP panel (SNMP command panel)
v IPSTAT (IP connections) panel
|
Setting Up TCP/IP Support for the AON IP Functions
The NetView program provides the following AON IP functions. (TCP390
definitions are required only for remote TCP/IPs and to override discovered data.)
|
|
146
Installation: Configuring Additional Components
|
|
|
|
|
|
|
|
|
Note: The configuration that is described in this section is for IP-related functions
that were previously implemented as part of the NetView Automated
Operations Network (AON) component. These functions, which are referred
to as the AON IP functions, are now implemented as base NetView services
and no longer require AON enablement and configuration.
v Stack monitoring
You can use the NetView program to automatically monitor stacks that have
been discovered by the NetView program or defined in TCP390 policy
definitions.
|
|
|
|
|
|
|
v IP connection management
Using the 3270, Web browser, or NetView management console, you can manage
IP connections into your stacks. All connections are supported, including
TN3270, FTP, CICS, and SMTP. You can use operator filters to assist in reducing
the amount of data. You can view connection byte counts and take action (for
example, breaking the connection).
v SNMP functions
|
|
|
|
|
|
|
|
|
Using 3270 panels, you can issue SNMP commands such as GET, SET, WALK,
and Remote Ping. You can also use the MIB groups function to define several
MIBs to be part of a group and use the NetView program to retrieve that group.
Sample MIB groups are provided.
v IP resource manager
Using the IP Resource Manager, you can display all of your critical IP resources
and their current status from 3270 panels. You can manage those resources using
pop-up windows.
v Proactive monitoring of IP resources
|
|
|
|
|
|
You can proactively monitor critical IP resources, including:
– IP stacks
– Hosts
– Interfaces
– Routers
– TN3270 servers
|
|
|
For example, you can define a performance MIB to query within a router and
define a threshold. When you exceed that threshold, the NetView program
notifies you of the problem.
|
|
|
|
v IP connection monitoring and thresholding
You can monitor IP connections such as printer connections and apply policy
definitions to determine if they are unavailable. You can choose to notify an
operator or use automation to break the connection.
|
|
|
|
|
|
|
v Intrusion Detection Services
You can use Intrusion Detection Services (IDS) support from the z/OS
Communications Server to delete the following IDS events and take actions:
– Scan detection
– Attack detection
– Traffic regulation for TCP connections
– UDP receive queues
|
|
|
|
Using the notification and inform policies, you can issue a message or generate
an alert, an IBM Tivoli Enterprise Console event, e-mail, or report based on a
particular event type.
v IP trace
|
|
Using 3270 panels or the Web browser, you can start and stop both component
and packet traces.
Chapter 7. Enabling IP Management
147
|
|
You can use Table 25 as you work through the installation tasks described in this
section.
|
Table 25. AON IP Function Enablement
|
|
Task
|
|
|
|
|
|
Update the CNMSTUSR or CxxSTGEN DSIPARM
member to enable the IPMGT tower.
(CNMSTYLE)
For information about changing
CNMSTYLE statements, see IBM Tivoli
NetView for z/OS Installation: Getting
Started.
IBM Tivoli NetView for
z/OS Installation: Getting
Started
|
|
|
|
|
|
|
|
|
Configure a UNIX command server
v DSIPARM
(CNMSTYLE)
v CNMSAMP
(CNMSJUNX or
CNMSSUNX)
v DSIPARM
(CNMPOLCY)
v DSIPARM
(CNMIPMGT)
“Defining UNIX Command
Servers” on page 149
|
|
|
Configure SNMP support
DSIPARM
(CNMSTYLE)
“Configuring SNMP Support
for AON IP Functions” on
page 150
|
|
Define at least one local MVS stack to
the NetView program (See the note.)
DSIPARM
(CNMPOLCY)
“Defining Local TCP/IP
Stacks” on page 150
|
|
|
|
As needed, define stacks for remote
NetView domains
v DSIPARM
(CNMSTYLE)
v DSIPARM
(CNMPOLCY)
“Setting Up Cross-Domain
Communication” on page 151
|
|
|
Set up monitoring of IP resources
DSIPARM
(CNMIPMGT)
“Setting Up for Proactive
Monitoring of IP Resources”
on page 152
|
|
|
If needed, update community names
DSIPARM
(CNMSCM)
“Resolving Community
Names (Optional)” on page
153
|
|
|
Enable TCP/IP connection
management
DSIPARM
(CNMIPMGT)
“Managing TCP/IP
Connections with AON IP
Functions” on page 153
|
|
|
Define the TCP/IP connection
monitoring policy
DSIPARM
(CNMIPMGT)
“Defining TCP/IP Connection
Monitoring Policy” on page
154
|
|
Enable Intrusion Detection Services
DSIPARM
(CNMSTIDS)
“Enabling Intrusion Detection
Services” on page 154
|
|
Enable TCP/IP component trace
DSIPARM
(CNMSTYLE)
“Customizing TCP/IP
Tracing” on page 155
|
|
Note: This can also be done by the NetView discovery manager.
Job or Member
Name
Reference
Defining AON IP Functions
|
Table 26 on page 149 summarizes the required and optional tasks necessary to
implement a particular AON IP function.
|
|
148
Installation: Configuring Additional Components
|
Table 26. Customization by Function
|
|
|
Task
TCP/
IP
Stack
UNIX
Cmd
Srvr
Rmt
Stacks
Rmt
Gtwys
Rmt
Srvr
Setup
Auto
tasks
|
Stack monitoring
RD
O
O
O
O
R/O
|
Ping command
RD
O
O
O
|
Tracerte command RD
O
O
O
|
|
Manage IP
connections
RD
O
O
|
|
|
SNMP GET /
SET/ and similar
tasks
RD
|
SNMP
Setup
SNMP
Comm
Name
R
O
R
O
O
R
O
SNMP MIB groups RD
O
R
O
|
|
SNMP remote
Ping
RD
O
R
O
|
|
IP resource
manager
RD
O
R
O
|
IP trace support
RD
O
|
|
Proactive
monitoring
RD
O
R
O
|
|
|
IP connection
monitoring and
thresholding
RD
R
O
|
|
Intrusion detection RD
automation
|
|
|
|
|
|
Note: The abbreviations in the table have the following meanings:
v R: Required task
v RD: Required definition, coding by user is optional
v O: Optional task
v R/O: Required task, customization is optional
|
O
O
R/O
R/O
R
TN
3270
Srvr
O
Monitoring
Method
O
R/O
Defining UNIX Command Servers
|
|
|
|
Determine the UNIX command servers that you need. UNIX command servers are
optional for Intrusion Detection Services (IDS); see “Enabling Intrusion Detection
Services” on page 154. For information about the requirements for the UNIX
command server setup, see “Enabling the UNIX Command Server” on page 208.
|
|
|
|
|
To set up a UNIX command server:
1. Allocate an MVS initiator for the UNIX command server. If the command
server is to be run as a started task, an MVS initiator is not required. Refer to
the online command help for DEFAULTS and START for more information
about running the UNIX command server as a started task.
|
|
|
|
Note: The DEFAULTS.STRTSERV statement in the CNMSTYLE member
specifies how the command server must be run.
2. Customize CNMSSUNX in CNMSAMP to enable the UNIX command server to
run as a started task. This is the default.
|
|
Note: If necessary, customize CNMSJUNX in CNMSAMP to enable the UNIX
command server to run as a submitted job.
Chapter 7. Enabling IP Management
149
|
|
|
|
|
>
3. Create additional CNMSJxxx or CNMSSxxx jobs for multiple TCP/IP stacks.
4. Authorize all IP management autotasks and any other operators to use the
UNIX command servers. The default autotask names are AUTIPM1 and
AUTIPM2 and are defined using the AUTOOPS policy definition in the
CNMIPMGT member. See “Defining TCP/IP Autotasks” on page 151 for task
names that need to be changed for your installation.
|
|
|
|
For the UNIX command server to start automatically for each stack during
initialization, specify UNIXSERV=YES on the TCP390 policy definition in
DSIPARM member CNMPOLCY. For more information, see “Defining Local
TCP/IP Stacks.”
Configuring SNMP Support for AON IP Functions
|
|
|
Most AON IP functions are SNMP-based. See the comments in the CNMSTYLE
member in DSIPARM to configure the NetView SNMP command.
|
|
|
|
|
|
|
To make updates, use the following statements in the CNMSTUSR or CxxSTGEN
member, and make any necessary modifications. For information about changing
CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
|
For security considerations, see the IBM Tivoli NetView for z/OS Security Reference.
COMMON.CNMSNMP.MIBS = all
COMMON.CNMSNMP.MIBPATH = /etc/netview/mibs:/usr/lpp/netview/v5r4/mibs
COMMON.CNMSNMP.timeout = 1
COMMON.CNMSNMP.retries = 5
Defining Local TCP/IP Stacks
|
|
|
At a minimum, define at least one local MVS stack to the NetView program, if it is
not defined automatically by the NetView discovery manager.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use the TCP390 policy definition in DSIPARM member CNMPOLCY to define a
local TCP/IP stack. The entire stack definition, or portions of it, are optional. The
NetView program dynamically determines information about your stack, such as
the IP address, host name, and TCP process name. If you want to use default
values for all functions (such as Intrusion Detection Automation Services), you do
not need to define a TCP390 statement for your stack. You need to define your
stack if you want to override the default settings. The following example defines a
local stack named NMPIPL10:
|
|
|
|
|
|
Notes:
TCP390
NMPIPL10,
IPADDR=9.67.50.52,
COMMUNITYNAME=private,
DOMAIN=LOCAL,
UNIXSERV=YES,
TCPNAME=TCPIP,
HOSTNAME=NMPIPL10.raleigh.ibm.com,
...
1. The stack NMPIPL10.raleigh.ibm.com is known as NMPIPL10.
2. SNMP requests (for example stack monitoring processes) uses a community
name of private.
3. The NetView domain managing this stack is the LOCAL domain. The local
domain is the same domain where this policy definition resides.
4. This policy defines a UNIX command server. For more information, see
“Defining UNIX Command Servers” on page 149.
|
|
150
Installation: Configuring Additional Components
|
|
|
|
|
|
|
|
5. You can specify either the IPADDR (recommended) or HOSTNAME parameter.
If you do not specify the IPADDR parameter, the NetView program
dynamically determines the IP address of the stack based on the HOSTNAME
parameter. This takes additional processor cycles.
6. For security, if you specify COMMUNITYNAME, restrict access to the member
containing your policy definitions.
7. TCPNAME defines the TCP/IP start procedure name. System symbolics can be
used, for example, you can use TCPNAME=&CNMTCPN.
|
|
For more information about the TCP390 policy definition, see the IBM Tivoli
NetView for z/OS Administration Reference.
|
Setting Up Cross-Domain Communication
|
|
|
Some IP functions (for example, connection management, SNMP functions,
monitoring functions, IP tracing functions, and commands) support communication
with remote NetView domains.
|
|
The discovery manager discovers all local stacks on a given system. Code TCP390
definitions for stacks on systems that are outside of your sysplex.
|
|
For example, to set up for cross-domain communication from NMPIPL10 (domain
NTV70) to NMPIPL27 (domain NTV9D):
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
v In NTV70, define TCP/IP stacks on the remote domain. For example, to define a
stack named NMPIPL27 in NetView domain NTV9D, use the following
definition:
|
|
For more information about TCP390 policy definitions, see the IBM Tivoli NetView
for z/OS Administration Reference.
|
TCP390
NMPIPL27,
IPADDR=9.67.50.41,
DOMAIN=NTV9D,
UNIXSERV=YES,
TCPNAME=TCPIP,
HOSTNAME=NMPIPL27.raleigh.ibm.com,
...
v In NTV9D, define the policy for the local stack:
TCP390
NMPIPL27,
IPADDR=9.67.50.41,
DOMAIN=LOCAL | lcldomid,
UNIXSERV=YES,
TCPNAME=TCPIP,
HOSTNAME=NMPIPL27.raleigh.ibm.com,
...
Defining TCP/IP Autotasks
|
|
|
|
Policy definitions are provided for two NetView autotasks that can be used for
TCP/IP automation and management. Review the following statement in the
CNMIPMGT member in DSIPARM:
|
|
|
This defines AUTIPM1 and AUTIPM2 as the autotasks that are used by the AON
IP functions. Modify this statement as necessary for your installation. If you
change the autotask IDs, also make changes to DSIOPF to define your task IDs.
|
|
For more information about the AUTOOPS statement, see the IBM Tivoli NetView
for z/OS Administration Reference.
AUTOOPS
TCPOPER,ID=(AUTIPM,2)
Chapter 7. Enabling IP Management
151
Setting Up for Proactive Monitoring of IP Resources
|
|
|
|
|
|
You can use the NetView program to proactively monitor your critical IP resources
based on policy definitions. You can use the following monitoring methods:
v “Pinging a Resource”
v “MIB Polling”
v “MIB Thresholding” on page 153
|
|
|
|
|
When proactive monitoring detects a failure, the following actions occur:
v The NOTIFY policy is used to determine the type of notification to be sent.
|
|
Table 27 shows the IP resource types you can monitor and the required policy
definitions.
|
Table 27. Control File Entries
|
Resource
Policy Definition
|
Host
IPHOST
|
Stack
TCP390
|
Router
IPROUTER
|
Interface
IPINFC
|
Socket
IPPORT
|
Server
IPNAMESERV
|
Telnet server
IPTELNET
|
TN3270 server
IPTN3270
|
IP connection
IPCONN
v A recovery monitoring timer is scheduled. This timer is scheduled as specified
on the MONIT policy definitions. The timer checks the resource status and
optionally sends a notification that the resource is still down.
|
|
|
|
As shipped, IPCONN definitions are commented out.
For more information about policy definitions, see the IBM Tivoli NetView for
z/OS Administration Reference.
|
|
|
|
Pinging a Resource
|
|
|
|
|
MIB Polling
|
|
|
|
|
|
|
To enable MIB polling, code FORMAT=SNMP, as shown in the following example:
To perform a ping of a resource, code FORMAT=PING on its policy definition. If the
ping response works, the resource status is NORMAL. If not, the resource status is
DOWN.
MIB polling uses SNMP to poll the interface table (ifTable) for the defined
resource. The administration status is compared to the operational status. If one or
more interfaces are expected to be up and are not, the resource is marked as
degraded. Degraded does not mean that the resource is down.
IPHOST HOST01,SP=NMPIPL10,
OPTION=IP390
ACTMON=ALLHOSTS,
FORMAT=SNMP,
STATUS=(NORMAL,DEGR*),
HOSTNAME=host01.raleigh.ibm.com
152
Installation: Configuring Additional Components
|
|
|
|
The ACTMON=ALLHOSTS statement refers to the following statement that contains a
common definition for monitoring all the IP hosts:
|
|
Using this definition, HOST01 is monitored every 30 minutes using a ping. The
expected status is NORMAL (resource is active).
|
|
Additionally, you can add the following status parameter so that a status of
degraded is not treated as a resource failure: STATUS=(NORMAL,DEGR*).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MIB Thresholding
IPHOST HOST01,SP=NMPIPL10,
OPTION=IP390
ACTMON=ALLHOSTS,
FORMAT=SNMP,
STATUS=(NORMAL,DEGR*,THRESH*),
MIBVAR=(ipRoutingDiscards.0,GE,3),
HOSTNAME=host01.raleigh.ibm.com
|
|
|
In this example, if the MIB value is greater than or equal to 3, the resource status is
set to THRESH. Notice also that THRESH is an acceptable status and therefore is
not treated as a resource failure.
|
ACTMON ALLHOSTS,OPTION=IP390,INTVL=00:30,STATUS=NORMAL,
FORMAT=PING
MIB thresholding uses SNMP to query MIBs defined in the policy definition for
the resource. You can define the MIB, its threshold value, and the threshold
operator (greater than, less than, equal). When the proactive monitoring timer
pops, the NetView program retrieves the MIB values and compares them to the
policy definition for the resource. For example, to add a MIB threshold to the
HOST01 resource and use the ipRoutingDiscards.0 MIB, code the following
statements:
Resolving Community Names (Optional)
|
|
|
When monitoring resources using SNMP, the NetView program might need access
to the community name for a resource. NetView SNMP reads MIB data from
community-name protected resources using DSIPARM member CNMSCM.
|
|
|
|
|
To use CNMSCM for community name resolution, add an entry line for each host
name to be resolved to a community name and then save the file. For more
information, see the IBM Tivoli NetView for z/OS Administration Reference. To
prevent unauthorized viewing or modification of CNMSCM, refer to the IBM Tivoli
NetView for z/OS Security Reference.
|
|
For information about defining community names to TCP/IP, see the z/OS
Communications Server IP Configuration Reference.
|
Managing TCP/IP Connections with AON IP Functions
|
|
|
TCP/IP connections can be established for any socket and can be established using
a TN3270 server. With the AON IP functions, you can manage these connections
from the 3270 interface, the NetView management console, or the Web browser.
|
|
To enable connection management, see Table 28 and “Enabling TCP/IP Connection
and Packet Trace Data Collection” on page 136.
|
Table 28. Connection Management
|
Connection
See
Chapter 7. Enabling IP Management
153
|
Table 28. Connection Management (continued)
|
To a local TCP/IP stack
|
“Defining Local TCP/IP Stacks” on page 150
Set up your local stack definition with SNMP capability.
|
To a remote TCP/IP stack
“Setting Up Cross-Domain Communication” on page 151
|
|
|
From a TN3270 server
“Setting Up for Proactive Monitoring of IP Resources” on
page 152 (TN3270 servers)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Because most stacks have numerous connections, consider limiting the amount of
data that your operator must view. To do this, you can use one of the following
methods:
v Code SESSTAT=NO on the IPPORT definition. All connection data for that port
is ignored. Code this for ports that you do not want to manage.
For example, if you do not want to manage connections with the NetView Web
server interface task:
IPPORT DSIWBTSK,SP=NMPNET10,
PORT=80,
PROTOCOL=TCP,
TCPNAME=NVPROCN,
STATUS=NORMAL,
FORMAT=PORT,
SESSTAT=NO,
DESC="NetView Web Browser Socket"
v For the Web browser, adjust the MAXCONN parameter. In the Web browser, you
can limit the number of connections shown based on the value of the
MAXCONN parameter on the TP390 DEFAULTS definition. Sample FKXCFG01
sets the limit to 1000. This limit applies to all connection types.
Defining TCP/IP Connection Monitoring Policy
|
|
|
|
You can monitor IP connections such as printer connections and apply policy
definitions to determine if they are stopped. You can choose to notify an operator
or use automation to break the connection.
|
|
|
|
|
To do this, customize the sample policy definitions in FKXCFG01:
*AUTOOPS CONNOPER,ID=AUTCMON
*ACTMON IPCONN,INTVL=00:01:00
*NOTIFY IPCONN,ALERT=NO,MSG=YES,DDF=NO,INFORM=NO
*IPCONN TCPIP*,
Enabling Intrusion Detection Services
|
|
|
|
|
To enable Intrusion Detection Services (IDS), review the IDS statements in the
CNMSTIDS member and update policy definitions in the CNMSTUSR or
CxxSTGEN member (see Table 29). For information about changing CNMSTYLE
statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
|
Table 29. IDS Support
|
Policy Definition
Update
|
|
|
TCP390
On the TCP390 stack policy definition, define your local
TCP/IP stack and specify IDSAUTO=Y and optionally specify
the IDSINTVL parameter.
154
Installation: Configuring Additional Components
|
Table 29. IDS Support (continued)
|
|
|
|
|
|
|
|
NOTIFY
|
|
|
|
|
NTFYOP
|
|
|
|
|
|
|
|
|
|
INFORM
|
|
|
|
|
By default, the NOTIFY IDSAUTO policy is set up to issue
alerts and messages for IDS events. You can optionally update
this policy to enable IDS events to be forwarded to the Tivoli
Enterprise Console. For example:
NOTIFY
IDSAUTO,
ALERT=TEC,
MSG=YES,
DDF=NO
Use the NTFYOP policy definition to define which NetView
operators receive IDS messages (class=64). For example:
NTFYOP
OPER1,
OPER='IDS-AUTO-SVCS',
CLASS=(64),HELDMSG=(I)
Update the Inform policy for e-mail notifications (reports and
responses to commands). For example:
GROUP IDSOPERS,LIST=OPER1,OPER2,OPER3;
INFORM OPER1;
CONTACT CONNECTION=EMAIL,
INTERFACE=EZLESMTP,
[email protected],
NAME=C. PERSON;
INFORM OPER2,...
INFORM OPER3,...
For more information, refer to sample EZLINSMP.
For more information about the policy definitions, refer to IBM Tivoli NetView for
z/OS Administration Reference.
Customizing TCP/IP Tracing
|
|
|
|
|
|
|
|
|
Output writers can be used to store trace data for later analysis. You can customize
the default output writer names for component or packet trace in the CNMSTYLE
member. Review the following statements for your environment and make changes
as appropriate in the CNMSTUSR or CxxSTGEN member. For information about
changing CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation:
Getting Started.
v Source JCL definitions for component and packet trace:
|
|
The Open Systems Adapter (OSA) trace does not have a default writer. You can
use the packet trace writer for OSA packet trace data.
v Time interval to wait for a response:
|
|
|
|
|
COMMON.EZLTCPcTRACEwriter = CTTCP
COMMON.EZLTCPpTRACEwriter = PKTCP
COMMON.EZLIPTraceJCLWait
= 2
// Component trace writer name
// Packet trace writer name
// ... for source JCL error response
For more information about IP tracing, see IBM Tivoli NetView for z/OS IP
Management. For information about the IPTRACE command, which enables trace
control through a panel interface, see the NetView online help.
Chapter 7. Enabling IP Management
155
156
Installation: Configuring Additional Components
|
|
Chapter 8. Configuring NetView Sysplex Management
|
|
|
|
|
|
To manage your sysplex from a single point of control with the NetView for z/OS
program, the NetView programs in your sysplex must participate in a z/OS XCF
group and must be defined as having one of the following roles: master NetView
program, master-capable NetView program, or basic NetView program.
Additionally, discovery manager and DVIPA management data needs to flow to
the master NetView program for display.
|
|
|
Using the NetView program for sysplex management requires the following
configuration:
v “Configuring XCF Services”
v “Configuring DVIPA Management for Display at a Master NetView Program” on
page 162
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
v “Configuring Discovery Manager for Display at a Master NetView Program” on
page 163
For information about managing sysplexes with the NetView program, see IBM
Tivoli NetView for z/OS IP Management.
Configuring XCF Services
The NetView program uses the z/OS cross-system coupling facility (XCF) to
maintain an XCF group of NetView programs within a sysplex. The sysplex
contains a master NetView program to which other group members forward
resource data. XCF services are used in exchanging control information among the
NetView programs and also in helping the NetView programs detect both other
NetView programs that are members of the group and the identity of the group
master.
Defining the NetView Role in a Sysplex
|
|
|
|
|
The role that a NetView program has is determined by a rank value that is
configured by using the XCF.RANK statement in the CNMSTUSR or CxxSTGEN
member. A NetView program can have one of the following roles:
v A master NetView program is one to which other NetView programs in the
sysplex forward discovered data. The user interfaces at the master NetView
program can display data at a sysplex level.
v A master-capable NetView program can become a master NetView program.
These can serve as a backup to the master NetView program.
|
|
v A basic NetView program forwards data to the master NetView program but
cannot assume the master role.
|
|
|
For more details about these roles, see the information about managing the
NetView program as a sysplex application in IBM Tivoli NetView for z/OS IP
Management.
|
|
|
|
The following values are valid:
v 250 indicates a master NetView program.
v 1 - 249 indicates a master-capable NetView program.
v 0 indicates a basic NetView program.
|
|
|
© Copyright IBM Corp. 2001, 2009
157
|
|
v -1 indicates a NetView program that is not a member of an XCF group. The data
for this NetView program can only be viewed locally.
|
|
For information about using CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started.
|
|
|
|
|
Many XCF CNMSTYLE statements are provided for configuring NetView XCF
services, and default values are supplied for all statements. Minimal configuration
is needed for a NetView program to use XCF. The only configuration that is
required is to specify the NetView program that is to be the master by setting the
rank for that NetView program to 250.
|
|
|
|
The default value of the XCF.RANK statement is 1, which means that a NetView
program is master-capable by default. For any NetView program that either should
be a basic NetView program or should not be in the XCF group at all, you need to
change the XCF.RANK value.
|
|
|
|
|
To control the order in which master-capable NetView programs take over the
master role when a master NetView program leaves the group, you must configure
the XCF.RANK value for the master-capable NetView programs. The
master-capable NetView program with the highest XCF.RANK value has the
highest priority in taking over as the master NetView program.
|
|
|
|
A number of optional functions can also be configured for a master NetView
program, including the following functions:
v Switching NETCONV connections or sessions from a former master NetView
program to a new master NetView program
|
|
|
|
|
|
|
|
|
v Initiating NETCONV connections or sessions to specified NetView management
console servers
v Initiating system jobs that should run on the system of the master NetView
program, such as Resource Object Data Manager (RODM) jobs or jobs that are
related to the NetView for z/OS Enterprise Management Agent
v Running a user-defined CLIST when a NetView program assumes the master
role
v Dynamically activating a dynamic virtual IP address (DVIPA) on the TCP stack
of the master NetView program
|
|
For a complete list and descriptions of XCF-related definition statements, see the
IBM Tivoli NetView for z/OS Administration Reference.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Consider the following items:
v NETCONV connections. XCF.TAKEOVER.CONVSNAxx and
XCF.TAKEOVER.CONVIPxx statements define NetView management console
servers to which a NetView program is to establish NETCONV connections if it
assumes the master role. The NetView program always issues NETCONV
commands when assuming the master role. The XCF.TAKEOVER.NETCONVS
statement controls whether the NetView program also attempts to take over
existing NETCONV connections or sessions from the previous master. These
connections or sessions do not have to be defined with CONVSNAxx or
CONVIPxx statements, nor are there any issues with taking over a connection or
session that is defined on a CONVSNAxx or CONVIPxx statement.
v Monoplex configurations. If a master-capable NetView program is running on a
monoplex or XCF-local system, there is no master NetView program until the
INITWAIT period has expired. This might cause problems if a master NetView
158
Installation: Configuring Additional Components
|
|
|
|
|
|
|
|
|
|
|
program needs to be available sooner. In these configurations, set the XCF.RANK
value to 250 to make the master NetView program available at initialization.
v Operator control of rank. The XCF.RANK and XCF.TAKEOVER.DURATION
definitions can be overridden by the PLEXCTL operator command. Operators
can dynamically change the rank. If an operator sets the rank by using the
PLEXCTL command, the operator request overrides the DURATION value that
is in effect at the current master.
v RMTCMD requirements. When a NetView program assumes the master role, it
sends RMTCMD commands to other NetView programs in the sysplex as part of
setting up data forwarding. RMTCMD support needs to be enabled on the
NetView programs in the sysplex group. Both SNA and IP are supported.
|
|
|
For more information about the use of XCF by a NetView program and about the
roles that a NetView program can assume in the sysplex group to which it belongs,
see IBM Tivoli NetView for z/OS IP Management.
|
Defining an Enterprise RODM
|
|
|
|
|
|
A master NetView program can establish connections to NetView programs that
are outside the sysplex in which it resides and have data forwarded to it. Typically,
this type of configuration is used to support a single RODM data cache for an
enterprise. Because XCF services are not available outside the scope of a sysplex,
you must configure the master NetView program to identify the NetView
programs to be contacted that are outside the sysplex.
|
|
|
|
|
|
If a contacted NetView program is a member of an XCF group in another sysplex,
information about all the members in the group is passed back to the sysplex
master that contacted it. Only one contact NetView program needs to be
configured for each sysplex, although you can configure additional backup
NetView programs. Note that these definitions also need to be available to any
master-capable NetView programs in the XCF group.
|
|
|
Use the following CNMSTYLE statements in the CNMSTUSR or CxxSTGEN
member to define the systems that are to be contacted when the enterprise master
NetView program assumes the master role in the sysplex in which it resides:
|
Statement
|
|
|
|
|
ENT.SYSTEMS.name
List the RMTCMD aliases that are used by the enterprise master
NetView program to contact other NetView programs within the
enterprise. The other NetView programs can be stand-alone
systems or members of another XCF group in another sysplex.
|
|
|
ENT.INT.name Set the pacing interval for data discovery commands that are sent
to contacted NetView programs when a NetView program assumes
the enterprise master role.
|
|
|
|
For more information about the statements and their default values, see the IBM
Tivoli NetView for z/OS Administration Reference or the comments in the CNMSTYLE
sample. For information about changing CNMSTYLE statements, see IBM Tivoli
NetView for z/OS Installation: Getting Started.
|
|
|
Description
Coordinating with TCP/IP Configuration for DVIPA Support
TCP/IP communication with the master NetView program (for example, using the
RMTCMD command) can be defined for the master NetView program. DVIPA
Chapter 8. Configuring NetView Sysplex Management
159
|
|
support associates the RMTCMD address with the master NetView program so
that RMTCMD requests always go to the master program.
|
|
|
|
|
When the master program moves in the sysplex, the address is dropped from the
stack of the old master program and is dynamically defined on the stack of the
new master program. When moving from a master NetView program to a
master-capable NetView program, the same IP address can be used to reach the
master NetView program.
|
|
To use DVIPA to represent the NetView application, define a block of IP addresses
(VIPARANGE) in the TCP/IP configuration.
|
|
For information about enabling DVIPA support, see “Enabling DVIPA
Management” on page 139.
Considerations for Master Switches
|
|
|
The master role in the sysplex can move from one NetView program to another for
several reasons:
|
|
|
|
|
|
v Stopping of the master NetView program
v The master NetView program leaving the group because a STOP XCFGROUP
command was issued
|
|
|
|
|
|
If more than one active NetView program is master-capable, the ranks of the
NetView programs that are specified by the XCF.RANK statements in the
CNMSTYLE member are used to determine the program that becomes the master
program, with the higher rank having precedence. If more than one NetView
program has the highest defined rank, a character comparison of the NetView
domain name is used.
|
|
|
|
|
|
|
|
|
|
|
|
The XCF.TAKEOVER.INITWAIT and XCF.TAKEOVER.DURATION statements in
the CNMSTYLE member can affect the process. These statements are intended to
prevent unnecessary, rapid master changes as systems become active and join the
sysplex group. If the sysplex group does not have a master (this can occur when a
master-capable NetView program starts and joins the group before the intended
master joins), the master-capable program waits for the interval specified by the
XCF.TAKEOVER.INITWAIT statement before assuming the master role. This gives
the intended master program time to start and join the group. When a
master-capable NetView program assumes the master role, it retains that role for
the time specified by the XCF.TAKEOVER.DURATION statement. Note that the
duration value might prevent a NetView program that starts with a rank of 250
from assuming the master role.
|
|
|
|
|
|
|
|
When the master role changes, the following actions that are controlled by
CNMSTYLE definition statements occur:
v The new master dynamically defines the DVIPA using the value that is specified
(if one is defined) in XCF.MASTDVIPA statement in the CNMSTYLE member.
v Manual intervention by using the PLEXCTL operator command
v XCF.RANK CNMSTYLE statement changes in the CNMSTUSR or CxxSTGEN
member that are implemented by the RESTYLE XCF command
v If the interval that is specified on the XCF.TAKEOVER.DELAY statement is
non-zero, a timer is set using the specified interval. The NetView program waits
until the timer expires to send CNMEERSC discovery commands to other
NetView programs in the sysplex group.
160
Installation: Configuring Additional Components
|
|
|
|
|
|
|
|
|
|
|
|
|
v XCF.proc.PROCSTR statements are processed. The NetView program checks the
job specified on the statement (using an MVS D A command). If the job is not
active, the NetView program generates an MVS START command for the job using
the specified procedure string.
v If the XCF.TAKEOVER.NETCONVS statement is set to YES, the NetView
program starts any NETCONV sessions that might be active on the former
master NetView program. Note that if the former master NetView program is
active, the new master NetView program sends NETCONV ACTION=STOP commands
to the former NetView program to end the connections prior to restarting them.
v Any new NETCONV connections specified with XCF.TAKEOVER.CONVIPnn or
XCF.TAKEOVER.CONVSNAnn statements are started.
v If a command list is specified on the XCF.TAKEOVER.CLIST statement, it is run.
Multiple NetView Groups
|
|
|
|
You can use the XCF.GROUPNUM statement to control the name of the XCF group
that the NetView program joins. The GROUPNUM value is appended to DSIPLX
to form the group name. This makes it possible to have multiple NetView XCF
groups within a sysplex, allocating the NetView program among different groups.
|
|
|
|
Each NetView program can join only one DSIPLXnn group (the one defined by the
XCF.GROUPNUM statement), although it can join additional user-defined groups.
Each DSIPLXnn group has a master and is independent of any other DSIPLXnn
group. Group members cannot use XCF services to communicate among groups.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Suppose that an installation runs separate automation and network NetView
programs on each LPAR in their sysplex, and that the NetView programs are to be
placed in separate XCF groups. The network NetView programs, which are named
NVNE1, NVNE2 and NVNE3, are to be placed in an XCF group with the default
group name of DSIPLX01. The automation NetView programs, which are named
NVAU1, NVAU2, and NVAU3, are to be placed in an XCF group with a group
name of DSIPLX02. NVNE1 and NVAU1 are the masters of their respective groups.
To accomplish this configuration, the following XCF configuration statements are
required:
v In the CNMSTUSR or CxxSTGEN member for NVNE1:
– XCF.RANK=250
v In the CNMSTUSR or CxxSTGEN member for NVAU1:
– XCF.RANK=250
– XCF.GROUPNUM=02
|
|
|
|
v In
–
v In
–
|
Note that no configuration is required for NVNE2 or NVNV3.
|
|
|
This configuration results in the following XCF groups:
v The DSIPLX01 group has members NVNE1, NVNE2, and NVNE3.
v The DSIPLX02 group has members NVAU1, NVAU2, and NVAU3.
the CNMSTUSR or CxxSTGEN member for NVAU2:
XCF.GROUPNUM=02
the CNMSTUSR or CxxSTGEN member for NVAU3:
XCF.GROUPNUM=02
Chapter 8. Configuring NetView Sysplex Management
161
|
|
|
Configuring DVIPA Management for Display at a Master NetView
Program
|
|
|
|
For DVIPA information to be displayed at the master NetView program, data must
be forwarded from other NetView programs in the sysplex to the master NetView
program. The master NetView program must be able to receive this forwarded
information and process it for display at the appropriate user interface.
|
|
|
|
|
|
|
Additional configuration for displaying DVIPA information at the master NetView
program can include the following items:
v Time to wait before the master NetView program updates DVIPA information in
the NetView for z/OS Enterprise Management Agent data space
v Processing of DVIPA events
v Capability to forward distributed DVIPA statistics to the master NetView
program
|
|
|
To ensure that DVIPA information is forwarded to the master NetView program for
display, ensure that the following configuration is complete on the non-master
NetView programs:
v The DVIPA tower and any subtowers are enabled.
|
|
|
|
v A RMTCMD session or connection with the master NetView program is active
and has an origin operator that matches the autotask that is defined in the
CNMSTYLE function.autotask.XCF statement.
|
|
|
|
Note: You can use the RMTCMD QUERY LCLAUTOS command to display the
RMTCMD session or connection.
v For logging of distributed DVIPA statistics at the master NetView program, the
CNMSTYLE DVIPA.STAT.Logto statement has a value of MasterOnly or ALL.
|
|
|
|
|
To ensure that DVIPA information is received and processed by the master
NetView program, ensure that the following configuration is complete at the
master NetView program:
v The DVIPA tower is enabled. The CNMSDVDS automation sample is included
by the DSITBL01 sample when the DVIPA tower is enabled.
|
|
|
|
|
v DSIIF004I message automation, which is shipped in the CNMSDVDS automation
sample, is active. The DSIIF004I message sends DVIPA data to the master
NetView program
v BNH867I message automation, which is shipped in the CNMSDVDS automation
sample, is active. The BNH867I message is used for distributed DVIPA statistics.
|
|
|
|
|
|
|
|
|
|
v DSIIF003I message automation, which is shipped in the CNMSDVDS automation
sample, is active. The DSIIF003I message is used to notify the master NetView
program that a DVIPA event was received for the specified system.
v If needed, the display of the NetView for z/OS Enterprise Management Agent
workspaces is enabled with the following actions:
|
|
Note: DVIPA connection and distributed DVIPA connection routing data is not
forwarded to the master NetView program due to potentially large volumes
– Enable the necessary TEMA subtowers.
– Review the DVIPA.Mast.EMARf.Delay statement in the CNMSTYLE member
to specify how long NetView waits to write data to the NetView for z/OS
Enterprise Management Agent data space. This delay allows multiple updates
to the data space to occur at one time.
162
Installation: Configuring Additional Components
|
|
|
|
|
|
of data. You can issue the 3270 commands and samples for these functions
from the master NetView program to retrieve real-time data from other
NetView domains.
Configuring Discovery Manager for Display at a Master NetView
Program
|
|
|
|
|
For discovery manager information to be displayed at the master NetView
program, data must be forwarded from other NetView programs in the sysplex to
the master NetView program. The master NetView program must be able to
receive this forwarded information and process it for display at the appropriate
user interface.
|
|
|
|
|
|
|
To ensure that discovery manager information is forwarded to the master NetView
program for display, ensure that the following configuration is complete on the
non-master NetView programs:
|
|
v The DISCOVERY tower and any subtowers are enabled.
v A RMTCMD session or connection with the master NetView program is active
and has an origin operator that matches the autotask that is defined in the
CNMSTYLE function.autotask.XCF statement.
Note: You can use the RMTCMD QUERY LCLAUTOS command to display the
RMTCMD session or connection.
|
|
|
|
|
|
|
|
|
|
To ensure that discovery manager information is received and processed by the
master NetView program, ensure that the following configuration is complete on
the master NetView program:
|
|
|
|
|
|
Note: DVIPA connection and distributed DVIPA connection routing data is not
forwarded to the master NetView program due to potentially large volumes
of data. You can issue the 3270 commands and samples for these functions
from the master NetView program to retrieve real-time data from other
NetView domains.
v The DISCOVERY tower is enabled. The CNMSEPTL automation sample is
included by the DSITBL01 sample when the DISCOVERY tower is enabled
v DSIIF002I message automation, which is shipped in the CNMSEPTL automation
sample, is active. The DSIIF002I message sends discovery manager data to the
master NetView program
v If necessary, TEMA subtowers are enabled to display the NetView for z/OS
Enterprise Management workspaces
Chapter 8. Configuring NetView Sysplex Management
163
164
Installation: Configuring Additional Components
Chapter 9. Defining and Maintaining Data Logs and Databases
|
This chapter includes the following steps that you can use to define the data logs:
v Maintaining the session monitor database
v Defining the JES job log
v Defining the network log
v Defining sequential access method logging support
v Printing the network log
v Installing the interactive problem control system
Maintaining the Session Monitor Database
The NetView session monitor component collects and stores data in a VSAM
database defined during the installation of the NetView product. This database
continues to grow in size unless you take action to periodically purge older data.
You can do this by using the NetView NLDM PURGE or PURGEDB command
with NetView timers.
|
A suggested strategy is to purge all records older than a particular age (for
example 30 days), and to purge a subset of records older than a lower value (for
example, 7 days). The criteria for identifying records in this second set is defined
using PURGE exception statements in the CNMSTYLE member.
|
|
|
To set up an exception list in the CNMSTYLE member, use PEXLSTxx statements
in the CNMSTUSR or CxxSTGEN member. For information about changing
CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
*NLDM.PEXLST01.A
*NLDM.PEXLST01.B
*NLDM.PEXLST02.A
*NLDM.PEXLST02.B
=
=
=
=
NCP* *
SSCP-SSCP
HOST1 NCP*
CP-CP
Change these statements to define the session monitor records that you do not
want purged if they are less than 30 days old. For example, to exclude SSCP-SSCP
and CP-CP records, specify the following statements:
NLDM.PEXLST01.A = SSCP-SSCP
NLDM.PEXLST01.B = CP-CP
To place these statements into effect, use the RESTYLE NLDM command.
The first step to automating the purge process is to setup a NetView timer to
purge all records older than 30 days:
EVERY 001,PPT,ID=NLDMP1,NLDM PURGEDB RT/SESS BEFORE -30
The second step to automating the purge process is to setup a NetView timer to
purge more recent records (older than 7 days):
EVERY 001,PPT,ID=NLDMP2,NLDM PURGEDB RT/SESS PEXLST01 BEFORE -7
If you want information about...
Refer to...
EVERY, PURGEDB, RESTYLE commands
IBM Tivoli NetView for z/OS Command
Reference Volume 1 (A-N)
PEXLSTxx statement
IBM Tivoli NetView for z/OS Administration
Reference
© Copyright IBM Corp. 2001, 2009
165
Defining the JES Job Log
If you are starting the NetView program specifying SUB=MSTR, the JES joblog is
allocated by default when the NetView task DSIRQJOB requests a job ID for the
NetView job. If you do not want the JES joblog, use the JesJobLog statement in the
CNMSTUSR or CxxSTGEN member, and modify it in the following way. For
information about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started.
|
|
|
|
JesJobLog=No
The default is Yes.
If you want information about...
Refer to...
JesJobLog statement
IBM Tivoli NetView for z/OS Administration
Reference
Defining the Network Log
The network log is defined using the CNMSJ004 job with the CNMSI101 input
member , and is used by the DSILOG task. The CNMSTYLE member determines
whether the NetView program starts the network log facility task during
initialization using the following statement:
|
TASK.DSILOG.INIT=Yes
If you change the TASK.DSILOG.INIT value to No (in CNMSTUSR or CxxSTGEN),
an operator must start DSILOG before any operator can use log browse. Otherwise,
domain_nameBRW is not able to complete initialization.
Defining Passwords for the Network Log
To define security passwords for the network log:
1. Stop the DSILOG task.
2. Modify the definition statements in CNMSI101 that define the network log,
changing them to include the specification of VSAM cluster passwords. Rerun
the CNMSJ004 job using these modified statements to delete and redefine the
network logs.
3. Update the CNMSTPWD member in DSIPARM to include the passwords that
you specified when redefining the network logs. The following example shows
the PWD statements that define the passwords for the network logs:
|
PWD.DSILOG.P = p_password
PWD.DSILOG.S = s_password
Where:
p_password
Is the 1- to 8-character password for the primary log.
s_password
Is the 1- to 8-character password for the secondary log.
4. Restart the DSILOG task.
Switching Recording Between Primary and Secondary Logs
Recording starts with the primary log and automatically switches to the secondary
log when the primary log fills. With the LOGINIT statement, you can specify
whether recording automatically switches back to the primary log when the
secondary log fills. You can also specify that recording is to resume where it left off
or restart at the beginning of the primary log.
166
Installation: Configuring Additional Components
In DSILOGBK, this LOGINIT statement is:
LOGINIT AUTOFLIP=YES,RESUME=YES
In the sample, when one log becomes full, recording automatically switches to the
other log. The full log can then be printed or dumped while recording continues.
CNMPRT (CNMSJM04) prints the log. If you do not want recording to switch
automatically to the primary log, specify AUTOFLIP=NO. If you have only one
log, recording always stops when the log is full.
In the sample, when the NetView program is started, recording resumes where it
left off If you want recording to start at the beginning of the primary log, specify
RESUME=NO.
If you want information about...
Refer to...
Printing logs
“Printing the Network Log”
Printing the Network Log
|
|
|
|
You can use the CNMPRT (CNMSJM04) job to print the network log. The
CNMSJM04 job was copied to your PROCLIB data set as CNMPRT during
installation. The NetView startup procedure, the CNMPROC (CNMSJ009)
procedure, also has commented-out JCL for printing the log.
Note: You can also use sample CNMS6214 to print the log.
|
To change the defaults used to print the network log, pass control statements to
PGM=DSIPRT using the DSIINP DD statement. You can do this using one of two
methods:
1. Create the following statements for a job stream or an instream procedure:
//DSIINP
DD *
PASSWD=password
OPER1,OPER2,NETOP1
RANGE_DELIM=delimiter
DATE_FORMAT=date_format
TIME_FORMAT=time_format
CONT_RANGE=[start_date] [start_time] delimiter [end_date] [end_time]
TIME_RANGE=[start_time] delimiter [end_time]
DATE_RANGE=[start_date] delimiter [end_date]
TRANSTBL MOD=DSIEBCDC
2. Create a statement similar to the following to define a data set member to
contain the print control statements, and put the preceding print control
statements in this member. Ensure that the print control statements do not
contain sequence numbers.
//DSIINP
DD
DSN=SYS1.PARMLIB(MEMBER),DISP=SHR
Only the second method applies for system-started JCL procedures.
Usage Notes for Print Control Statements:
|
|
|
1. If you defined passwords for the network log, add a PASSWD statement:
PASSWD=password
Chapter 9. Defining and Maintaining Data Logs and Databases
167
2. You can limit the output that is produced by specifying one or more operator
IDs or tasks, separated by commas or blanks. For example, to limit the output
to records related to operators OPER1, OPER2, and NETOP1, specify the
following statement:
|
OPER1,OPER2,NETOP1
3. You can specify the range delimiter that you want to use when specifying a
date and time range:
RANGE_DELIM=
—
delimiter
where: delimiter is a 1-character symbol that is used to separate the start date
and time from the end date and time. The delimiter must be different from any
delimiter used in either the DATE_FORMAT or TIME_FORMAT statements.
The default is a dash (-).
Note: The RANGE_DELIM statement must precede the DATE_FORMAT or
TIME_FORMAT statements.
4. You can specify the date format that you want to use when specifying a date
value in subsequent range parameters:
DATE_FORMAT=
MM/DD/YY
date_format
where:
date_format
Specifies the order of the month (MM), day (DD), and year (YY), and
also 1-character non-alphanumeric delimiters between the values. This
delimiter must be different from the delimiter in effect for
TIME_FORMAT and RANGE_DELIM.
Notes:
a. You can specify the month, day, and year in any order.
b. If you specify the month, day, and year, this indicates the month, day
within the month, and year. If you specify only the year and day, this
indicates the year and the day of the year (Julian date).
c. You can specify one or multiple M, D, and Y characters for the date. For
example, the following format specifies the day, followed by the month and
year using a dash for the delimiter:
DATE_FORMAT=DD-MM-YYYY
The following format specifies a Julian date using a period for a delimiter:
DATE_FORMAT=YYYY.DDD
d. If you omit the DATE_FORMAT parameter, the default is MM/DD/YY.
5. You can specify the time format that you want to use when specifying a time
value in subsequent range parameters:
TIME_FORMAT=
HH:MM:SS
time_format
where:
time_format
Specifies the order of the hour (HH), minutes (MM), and seconds (SS),
and also 1-character non-alphanumeric delimiters between the values.
168
Installation: Configuring Additional Components
This delimiter must be different from the delimiter in effect for
DATE_FORMAT and RANGE_DELIM.
Notes:
a. You can specify the hour, minutes, and seconds in any order.
b. You can specify one or multiple H, M, and S characters for the time. For
example, the following format specifies the hour followed by the minutes,
using a colon for the delimiter:
TIME_FORMAT=HH:MM:SS
c. If you omit the TIME_FORMAT parameter, the default is HH:MM:SS.
6. You can limit the output by specifying a starting and ending date and time
range.
Use the CONT_RANGE parameter to specify a continuous range of time from
one point in time to another.
Use the TIME_RANGE parameter to limit entries to a specific range of time for
each day. Use the DATE_RANGE parameter to limit entries to a specific range
of dates. You can specify both a TIME_RANGE and DATE_RANGE parameter.
CONT_RANGE=
start_date
TIME_RANGE=
start_time
DATE_RANGE=
start_date
delimiter
start_time
delimiter
end_time
delimiter
end_date
end_date
end_time
where:
start_date | end_date
Specifies the date in the format defined by the DATE_FORMAT control
parameter.
|
|
The default start_date is the earliest date in the log. The default end_date
is the last date in the log.
start_time | end_time
Specifies the time in the format defined by the TIME_FORMAT
parameter.
The default start_time is 00:00:00 (midnight).
The default end_time is 23:59:59 (one second before midnight).
delimiter
Specifies the delimiter as defined on the RANGE_DELIM parameter. If
you omitted the RANGE_DELIM parameter, use a dash (-) for the
delimiter.
Notes:
a. Specify DATE_FORMAT, TIME_FORMAT, and RANGE_DELIM before
CONT_RANGE, DATE_RANGE, and TIME_RANGE.
b. Do not specify CONT_RANGE if you specify either TIME_RANGE,
DATE_RANGE, or both.
Examples:
a. To limit entries to those dated from August 1, 2009, until August 10, 2009,
use:
DATE_RANGE=8/1/09-8/10/09
b. To limit entries to those that occur from 7:00 A.M. to 5:00 P.M. (within
DATE_RANGE, if specified), use:
Chapter 9. Defining and Maintaining Data Logs and Databases
169
TIME_RANGE=7:00:00-17:00:00
c. To limit entries to those that occur from August 7, 2009, starting at 10:00
A.M., until August 10, 2009, ending at noon, use:
CONT_RANGE=8/7/09 10:00:00 - 8/10/09 12:00:00
7. To support a non-EBCDIC character set, use a TRANSTBL statement in the
CNMSTUSR or CxxSTGEN member to specify the same module that is
specified in the TRANSTBL statement in the CNMSTYLE member. For
information about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started.
|
|
|
TRANSTBL MOD
=
module
For example, if your system supports kanji, use the following statement:
TRANSTBL MOD=DSIKANJI
8.
Any statement with an asterisk (*) in column 1 is considered a comment, and
is ignored by DSIPRT.
Defining Sequential Access Method Logging Support
NetView sequential access method log support makes it possible to:
v Define a primary and secondary output data set
v Define one or more sequential log tasks
v Interface to the sequential log subtask
Basic Sequential Access Method (BSAM) is the sequential logging access method
used.
The information discussed here only shows how to define sequential log tasks and
data sets to your system.
If you want information about...
Refer to...
Deciding whether you want to use sequential IBM Tivoli NetView for z/OS Customization
logging support and how to use it
Guide
Allocating and Defining a Sequential Log Data Set
For each sequential data set that NetView processes, there must be a corresponding
DCB and DD statement in the NetView start procedure. The characteristics of the
data set and device-dependent information can be supplied by either source. The
DD statement must also supply data set identification, device characteristics, and,
if necessary, space allocation requests.
The NetView program defines the data control block (DCB) information with a
subset of its parameters to ensure that it can use BSAM to write variable blocked
records to a physical sequential data set. You can tailor other parameters, such as
BLKSIZE, to meet your needs. The following parameters are coded on the NetView
DCB statement and cannot be coded on the DD statement:
DSORG=PS
RECFM=VB
MACRF=(R,W)
KEYLEN=0
Another way to allocate a sequential log data set is by using the ALLOCATE
command, which can dynamically allocate a sequential log. The log is accessible by
all NetView tasks just as if you had coded a DCB and DD statement in the
170
Installation: Configuring Additional Components
NetView start procedure.
If you want information about...
Refer to...
The ALLOCATE command
IBM Tivoli NetView for z/OS Command
Reference Volume 1 (A-N)
Block Size (BLKSIZE)
BLKSIZE is the maximum size of a block of records that can be written. A
minimum of 150 bytes is required. If you do not specify the BLKSIZE, or if its
value is less than 150 bytes, the NetView system sets the BLKSIZE to 4096 bytes,
without notification. You can use the NetView program to tailor the BLKSIZE of
the data set according to the needs of the data. If the NetView program is given an
acceptable BLKSIZE, but the size is not valid for a particular data set,
unpredictable results can occur.
The BLKSIZE for the primary and secondary data sets must be the same. The
BLKSIZE of the primary data set is used to set the BLKSIZE of the secondary data
set. The NetView program sets the LRECL 4 bytes less than the BLKSIZE. If the
NetView program attempts to log a record that is too large for the BLKSIZE you
have defined, message CNM484I is issued, the record is truncated, and processing
continues.
BLKSIZE affects the performance of the sequential log function. The size of the
output buffer and the frequency of sequential log requests determine the number
of I/O requests.
Notes:
1. A date and time header record is written to your sequential log at the
beginning of each block of records. You can alter the format of this record by
coding the XITBO exit routine.
2. The first 2 bytes of this record contain a flag that is used when the log is
resumed. Do not change these 2 bytes if you ever resume this log.
If you want information about...
Refer to...
XITBO (BSAM output exit routine)
IBM Tivoli NetView for z/OS Programming:
Assembler
Data Set Disposition (DISP)
You can define the data disposition (DISP). DISP controls the status of the data set
and shows what is to be done with it at the end of the job. Allowing the data set
to be shared permits read access to the sequential log data set by other jobs.
Defining the Sequential Logging Function
|
|
|
|
To use the sequential logging function, use the following task statements in the
CNMSTUSR or CxxSTGEN member, and modify them as needed. For information
about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started.
*TASK.SQLOGTSK.MOD=DSIZDST
TASK.SQLOGTSK.MEM=SQLOGMEM
TASK.SQLOGTSK.PRI=2
TASK.SQLOGTSK.INIT=N
Chapter 9. Defining and Maintaining Data Logs and Databases
171
SQLOGMEM is the name of the member in DSIPARM that specifies the
initialization parameters for the sequential logging task SQLOGTSK. The following
definitions are the initialization definitions:
DSTINIT FUNCT=OTHER
Include this statement, and code FUNCT=OTHER.
DSTINIT DSRBO=1
The system default is 3, but for this task use only 1.
DSTINIT PBSDN=SQLOGP
This is the primary log DDNAME and must be the same name specified
on the DD statement in the CNMPROC (CNMSJ009) member or defined by
the ALLOCATE command.
DSTINIT SBSDN=SQLOGS
This is the secondary DDNAME and must be the same name specified on
the DD statement in CNMPROC (CNMSJ009) or defined by the
ALLOCATE command.
DSTINIT XITBN=xxxxx
This is the data set initialization routine.
DSTINIT XITBO=xxxxx
This is the sequential log output exit routine.
LOGINIT AUTOFLIP=YES
This permits the NetView system to switch from a secondary data set that
is out of space to the primary data set. The NetView system always
switches from the primary to the secondary if the out-of-space condition
occurs on the primary data set.
LOGINIT RESUME=NO
This tells the NetView system not to resume processing of the sequential
log data sets at task startup. If you code RESUME=YES, the NetView
program determines which of the two data sets (PBSDN or SBSDN) was
last used for sequential logging. Later logging of data is appended to that
data set. After the initial RESUME, any switching of data sets, for a manual
switch or automatic switch (AUTOFLIP), begins writing records at the top
of the output data set. The previous data is erased.
Note: Code RESUME=NO for the first use of the log data set. This causes
the NetView program to initiate the data set.
DSIPARM member CNMCMENT contains the following CMDDEF statements for
the sequential logging function:
CMDDEF.DSIBSWCP.MOD=DSIBSWCP
CMDDEF.DSIBSWCP.TYPE=D
CMDDEF.DSIBSWCP.SEC=BY
CMDDEF.DSIZBSQW.MOD=DSIZBSQW
CMDDEF.DSIZBSQW.TYPE=RD
CMDDEF.DSIZBSQW.PARSE=N
CMDDEF.DSIZBSQW.SEC=BY
172
If you want information about...
Refer to...
The DSTINIT statement
IBM Tivoli NetView for z/OS Administration
Reference
The NetView installation exits
IBM Tivoli NetView for z/OS Programming:
Assembler
Installation: Configuring Additional Components
CNMPROC (CNMSJ009)
Figure 14 is an example of a sequential log task, USRSQLOG, using a tape
(TAPEOUT) as the primary output data set, and a DASD data set as the secondary
data set. The DD statement gives the NetView program access to the sequential log
data sets. This example also illustrates how to use BLKSIZE and DISP with DD
statements.
Note: Because of device dependencies, certain combinations of primary and
secondary database definitions might not be allowed in your system
environment.
//*CNMSJ009 JOB 'ACCOUNTING INFORMATION','NETVIEW STARTUP PROC',
//*
CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)
.
.
.
//NETVIEW EXEC PGM=&PROG,TIME=1440,
//
REGION=&REG.K,PARM=(&BFSZ.K,&SLSZ),
//
DPRTY=(13,13)
DCB=(BLKSIZE=200)
.
.
.
//BNJ36SE DD
DSN=&VQ1..SA&SA..BNJ36SE,
//
DISP=SHR,AMP=AMORG
.
.
.
//TAPEOUT DD DSN=data_set_name,DISP=(,KEEP),
//
VOLUME=(PRIVATE,RETAIN,,,SER=tape#),
//
UNIT=unit addr,
//
LABEL=(,NL),
//
DCB=(BLKSIZE=200)
//DASDOUT DD DSN=data_set_name,DISP=SHR,
//
VOLUME=SER=serial_number,
Figure 14. Example of a Sequential Log Task
Installing the Interactive Problem Control System
The interactive problem control system (IPCS) is a component of MVS that you can
use for diagnosing software failures. IPCS makes it possible to:
v Format and display dump data
v Locate modules and control blocks
v Validate control blocks
v Check certain system components
IPCS also provides a verb exit interface whereby a verb exit routine can be written
to generate a unique diagnostic report that is not currently available in IPCS. For
more information about IPCS, refer to the Interactive Problem Control library.
The NetView program supplies an IPCS verb exit routine, CNMIPCS, that you can
use to analyze dumps of the NetView program from an MVS system.
The NetView IPCS code must be installed in the data set defined by a CNMLINK
DD statement. If you place CNMLINK in the LNKLST, the IPCS automatically has
access to the code. If you have not included CNMLINK in LNKLST, remember to
STEPLIB to this code in the TSO LOGON procedure that you use with IPCS.
The NetView IPCS code supports an ISPF panel interface. These panels need to be
installed in the data set defined by an SCNMPLIB DD statement in NetView. If
you want TSO users to use the panel interface, concatenate this data set to the
ISPPLIB DD statement in the appropriate TSO LOGON procedure.
The following example shows this process:
Chapter 9. Defining and Maintaining Data Logs and Databases
173
//IPCSPROC
//STEPLIB
//
//ISPPLIB
//
//
//....
EXEC
DD
DD
DD
DD
DD
PGM=IKJEFT01,DYNAMNBR=70,REGION=3072K
DSN=NETVIEW.V5R4M0.CNMLINK,DISP=SHR
DSN=SYS1.MIGLIB,DISP=SHR
DSN=ISP.SISPPENU,DISP=SHR
DSN=ISF.SISFPENU,DISP=SHR
DSN=NETVIEW.V5R4M0.SCNMPLIB,DISP=SHR
Note: If you have included the CNMLINK data set in your STEPLIB
concatenation, and subsequently include it in the LNKLST concatenation,
remove the STEPLIB statement from your TSO LOGON procedure.
174
If you want information about...
Refer to...
IPCS
IBM Tivoli NetView for z/OS Troubleshooting
Guide
Installation: Configuring Additional Components
Chapter 10. Centralizing Operations
This section includes steps that you can use to centralize your operations.
Forwarding Data to Architectural Focal Points
|
|
NetView architectural focal point support is based on the focal point architecture
described in the SNA library. With this architecture, the sender of the data is an
entry point application and the receiver is a focal point application. The data is broken
down into categories, for example ALERT and OPS-MGMT are categories of data.
The entry point and focal point applications can be provided with the NetView
program or defined by users. Data is sent (forwarded) from an entry point to its
focal point over the MS transport. The entry points and focal points need not be
NetView programs, for example an entry point NetView program can send alerts
to a non-NetView product such as AS/400®. Products that conform to the
architecture can serve as a focal point or entry point for the NetView program.
When defined, an entry point NetView program can send data to its focal point
over the MS transport, and a focal point NetView program can receive data from
its entry points over the MS transport. The following sections explain the
definitions necessary to define the NetView program as an architectural entry point
application and an architectural focal point application for the OPS-MGMT, ALERT,
and user-defined categories.
Because data is sent to architectural focal points over the MS transport, when
switched lines are used, the NetView program does not perform the dial to
establish the connection. Dialing is done by the VTAM program. Also, the NetView
program does not control whether the MS transport uses persistent or
nonpersistent sessions. Use the VTAM program to make this decision.
If you want information about...
Refer to...
Architectural focal point concepts and
applications
IBM Tivoli NetView for z/OS Automation Guide
Forwarding Operations Management Data through LU 6.2
|
|
The operations management support function enables applications that are
supplied by IBM or written by users to send architectural operations management
commands and requests to remote systems for processing, and to receive
operations management reports from those remote systems.
In cooperation with the focal point support function, operations management
support also enables a served application in an entry point node to be informed of
the identity of the focal point for unsolicited operations management data. The
served application sends operations management data to a focal point using the
management services (MS) transport.
|
The CNMSTYLE member contains the following MS transport task statement:
TASK.DSI6DST.INIT=Yes
© Copyright IBM Corp. 2001, 2009
175
If you want information about...
Refer to...
The MS transport
“Defining Management Services Transport”
on page 119
The operations management support function IBM Tivoli NetView for z/OS Application
Programmer’s Guide
To define a focal point for operations management data, use the DEFFOCPT and
DEFENTPT statements. Use the DEFFOCPT or DEFENTPT statement at the entry
point, but you do not need to use either statement at the focal point.
DEFFOCPT Statement
The DEFFOCPT statement defines primary and backup focal points for operations
management data. To define a focal point for operations management data, add or
uncomment the DEFFOCPT statements in DSI6INIT.
Note: DSI6INIT is the initialization member for the DSI6DST task.
The following statements are the relevant DEFFOCPT statements in DSI6INIT:
* DEFFOCPT
* DEFFOCPT
TYPE=OPS_MGMT,PRIMARY=NETA.CNM02,BACKUP=NETB.CNM99
TYPE=OPS_MGMT,BACKUP=CNM03
Where:
PRIMARY
Specifies the name of the domain that is used as the primary focal point.
TYPE=OPS_MGMT
Specifies that operations management data is sent to the focal point.
BACKUP
Specifies the name of the domain that is used as the backup focal point.
OVERRIDE
Specifies that all DEFFOCPT statements are used at initialization regardless
of whether any focal point details for this category are found in the VSAM
save/restore database.
Uncomment these statements and change the primary and backup focal point
names to match your network names.
DEFENTPT Statement
Use the DEFENTPT EPONLY statement in DSI6INIT to set up the operations
management function as an entry point or a focal point. The DEFENTPT statement
only applies to the operations management category. The DEFENTPT statement is:
* DEFENTPT
EPONLY=NO
Where:
EPONLY=NO
Specifies that this host is a focal point for operations management data,
and an entry point. NO is the default.
If you define a focal point using the DEFFOCPT statement at this host, the
DEFENTPT statement is automatically set to EPONLY=YES.
If you use the DEFENTPT statement to define your host as an entry point, you can
use the CHANGE keyword on the FOCALPT command to define a focal point
176
Installation: Configuring Additional Components
(without using a DEFFOCPT statement). Here, issue the FOCALPT CHANGE
command from a focal point or a FOCALPT ACQUIRE command from the entry
point to establish a focal point relationship for operations management data.
Forwarding Alerts through LU 6.2
The alert function requires that the DSI6DST task be active. The hardware monitor
BNJDSERV task must also be active.
You can use the hardware monitor recording filters to choose which alerts the
NetView program needs to forward. The ROUTE filter selects alerts for forwarding.
However, an alert must pass the ESREC and AREC filters before it goes to the
ROUTE filter.
You can use the SRFILTER command to specify filter settings from the hardware
monitor, or you can use the SRF action to specify them from the automation table.
For more information about the SRFILTER command, refer to the online help.
A forwarded alert is filtered a second time on the focal-point system. The alert is
always logged as an alert in the hardware monitor database of the focal point
system (it cannot be blocked with the SRFILTER command or the automation table
SRF action). The ROUTE filter cannot forward the alert a second time.
Setting Up an Alert Focal Point
The architectural alert support permits the hardware monitor to act as an
ALERT-NETOP application. This enables the hardware monitor to receive alerts
over LU 6.2 from entry point applications. You do not need to perform any setup
to start this function, other than to ensure that the DSI6DST and BNJDSERV tasks
are active.
Setting Up an Alert Entry Point
The architectural alert support permits the NetView hardware monitor
ALERT-NETOP application to act as an EP-ALERT (entry point for category
ALERT) application. This enables ALERT-NETOP to forward alerts over LU 6.2 to
the current alert focal point.
By default, ALERT-NETOP sends alerts over LUC as described in “Forwarding
Alerts through LUC” on page 182.
|
To send alerts over LU 6.2 (the recommended alert forwarding method), ensure
that the following statement in the CNMSTYLE member is not commented out:
NPDA.ALERTFWD = SNA-MDS-LOGONLY
For information about the LOGONLY, AUTHRCV, and SUPPRESS options, refer to
the NPDA.ALERTFWD statement in the IBM Tivoli NetView for z/OS Administration
Reference.
Uncommenting the NPDA.ALERTFWD statement enables ALERT-NETOP to act as
an entry point. This enables ALERT-NETOP send alerts to its focal point. To define
the focal point that receives these forwarded alerts, uncomment the following
DEFFOCPT statement in DSI6INIT, replacing the primary focal point name of
NETA.CNM02 with your specified focal point name.
*
DEFFOCPT TYPE=ALERT,PRIMARY=NETA.CNM02
You can specify one to eight backup focal points.
Chapter 10. Centralizing Operations
177
If your specified alert focal point is typically going to be a non-NetView product,
such as an AS/400, the non-NetView product might not receive all alerts that the
NetView program sends, because the NetView program might send alerts that do
not conform to the SNA library architecture (and the receiving product does not
know how to process them) or the non-NetView product does not have various
subsets of the architecture. Refer to the IBM Tivoli NetView for z/OS Automation
Guide for more information.
After the ALERTFWD and DEFFOCPT statements are specified, when you next
restart the NetView program the hardware monitor ALERT-NETOP application
forwards all alerts it receives to the alert focal point defined in the DEFFOCPT
statement, if the focal point is available.
Setting up an Intermediate Node Alert Focal Point
When the ALERT-NETOP application receives alerts that were sent from entry
points over LU 6.2, ALERT-NETOP can forward these alerts again to its alert focal
point over either LU 6.2 or LUC. Only alerts received over LU 6.2 can be sent
again; alerts received over LUC are never sent again. Because ALERT-NETOP
receives alerts from entry points and forwards alerts to its focal point, the NetView
program is an intermediate node alert focal point.
Setting up an Intermediate Node to Forward Alerts through LU 6.2: To set up an
intermediate node to forward alerts over LU 6.2, see “Setting Up an Alert Entry
Point” on page 177. Notice that the setup for an intermediate node to forward
alerts over LU 6.2 is exactly the same as the setup for an entry point to forward
alerts over LU 6.2. This is because the intermediate node is itself an entry point.
CNMSTYLE: When a NetView intermediate node receives an alert over LU 6.2,
alert data is recorded to the hardware monitor database. You might want the alert
to simply pass through the intermediate node without alert data being recorded on
the database. To specify this, the following ALRTINFP statement is defined in the
CNMSTUSR or CxxSTGEN member. For information about changing CNMSTYLE
statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
|
|
|
NPDA.ALRTINFP.RECORD = Yes
See the IBM Tivoli NetView for z/OS Administration Reference for more information
about the ALRTINFP statement. ALRTINFP applies only when alerts are received
over LU 6.2 and then sent again over LU 6.2. Use the default of ALRTINFP
RECORD, which records alert data to the hardware monitor database.
Setting up an Intermediate Node to Forward Alerts through LUC: To set up an
intermediate node to forward alerts over LUC, see “Forwarding Alerts through
LUC” on page 182. While it is possible to have an entry point NetView program
forwarding alerts over LU 6.2 and an intermediate node NetView program
forwarding alerts over LUC, it is recommended that all NetView nodes use LU 6.2
to forward alerts.
Additional Considerations for Forwarding Alerts through LU 6.2
Additional considerations for forwarding alerts over LU 6.2 include:
v TAF
Operators at the centralized host can perform problem determination by
accessing the remote host using terminal access facility (TAF) or cross-domain
function.
178
Installation: Configuring Additional Components
Additional TAF source LUs might be required, depending on the number of
operators that access remote hosts using the terminal access facility. For more
information, see “Defining the Terminal Access Facility” on page 186.
v Hardware monitor
The hardware monitor tasks must be active to forward alerts. Enter the
STARTCNM NPDA command to start the hardware monitor tasks if they are not
active.
The hardware monitor must be active on the focal point host for GMFHS to
provide the correct status for native resources. The hardware monitor must also
be active on every distributed system that supports service points used to collect
status for the native resources.
Forwarding Alerts Using TCP/IP
|
When you want to receive alerts over a TCP/IP connection, initialize the DSIRTTR
task. The DSIRTTR task works with DSICRTR. The following statements are the
related statements in the CNMSTYLE member:
RTT.PORT
Specifies the port that is used by the status focal point host for TCP/IP
communication. The default is 4021.
RTT.SOCKETS
Specifies the maximum number of sockets this status focal point host can
use for connecting to programmable workstations. The default is 50.
RTT.TCPANAME
Specifies the TCP/IP application procedure name that the status focal point
host uses. This is a required keyword for the TCP/IP function.
|
|
|
You can start the DSIRTTR task automatically during NetView initialization by
using the following task statement in the CNMSTUSR or CxxSTGEN member and
changing INIT=N to INIT=Y. For information about changing CNMSTYLE
statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
TASK.DSIRTTR.INIT=Y
Forwarding User-Defined Data through LU 6.2
Like all architectural focal point functions, user-defined entry point and focal point
applications require that the DSI6DST task, described in “Forwarding Operations
Management Data through LU 6.2” on page 175, be active.
Setting Up a User-Defined Focal Point
Your user-defined focal point application must register with the MS transport.
When registered, entry point applications can forward data to it.
Setting Up a User-Defined Entry Point
Your user-defined entry point application must register with the MS transport with
interest in your user-defined category of data (the focal point application name).
When registered, the MS-CAPS application notifies your entry point application of
your focal point netid.nau name, which MS-CAPS obtains from the DEFFOCPT
statement. Your entry point application can then begin forwarding data to your
focal point application. If your focal point application becomes unavailable, for
example because of a line break, MS-CAPS notifies your entry point application
that you have no focal point and MS-CAPS tries to acquire a backup focal point.
To define the focal point for your user-defined category, uncomment the following
DEFFOCPT statement in DSI6INIT, replacing the primary focal point name of
Chapter 10. Centralizing Operations
179
NETA.CNM02 with your preferred focal point netid.nau name and replacing
USERCAT with your user-defined category name (which is identical to your
user-defined focal point application name).
*
DEFFOCPT TYPE=USERCAT,PRIMARY=NETA.CNM02,OVERRIDE
You can specify one to eight backup focal points if you wish.
Defining the Entry Points in the Sphere of Control of a Focal
Point
The sphere of control of a focal point is all of the entry points that have an
established relationship with a registered focal point.
Using the sphere of control function, operators at a focal point can manage all focal
point-entry point relationships, which includes the ability to perform the following
tasks:
v Display all entry points in the sphere of control of a focal point.
v Delete entry points from the sphere of control of a focal point.
v Dynamically refresh the sphere of control environment.
The focal point sphere of control environment is defined in the sphere of control
configuration file DSI6SCF. This file defines:
v Entry point names
v Primary focal point categories
v Primary focal point names
v Backup focal point names (optional)
The sphere of control manager (SOC-MGR) at the focal point reads the
configuration file under the following circumstances:
v During NetView initialization to set up the focal point-entry point sphere of
control environment
v When an operator issues the FOCALPT REFRESH command to update the
sphere of control environment
Note: The SOC-MGR does not read the configuration file at initialization when
both of the following conditions exist:
v Save/restore data exists
v DSISVRT is active
Define which entry points are to be explicitly obtained into the sphere of control of
a focal point in the sphere of control configuration file DSI6SCF. Add a one-line
statement in DSI6SCF for each entry point node. The format for each statement in
the configuration file is:
EPNAME
FPCAT
PRIMARY FP
BACKUP FP
Where:
EPNAME
Is the name of the network and LU or VTAM CP name (netid.nau) where the
entry point resides. For the NetView program, the LU name is the NetView
domain name. netid is optional. If you specify an asterisk (*) for netid, VTAM
determines the netid of the LU.
180
Installation: Configuring Additional Components
Note: If two nodes in two different networks have the same LU name, the one
that VTAM finds can vary depending on the configuration of nodes that
are active at a time.
FPCAT
Defines the focal point category. This definition makes it possible for you to
specify the initial primary backup focal point settings for the specified
category. The following categories are valid:
OPS MGMT
Specifies that the category is operations management.
ALERT
Specifies that the category is alert.
SPCS
Specifies that the category is SPCS.
user_defined
Specifies that the category is a user-defined category.
PRIMARY FP
Is the name of the network and LU or VTAM CP name (netid.nau) where the
focal point resides.
BACKUP FP
Is the name of the network and LU or VTAM CP name (netid.nau) where the
backup focal point resides. The backup focal point is optional.
The following example shows the entries in a sphere of control configuration file:
* EPNAME
*-------------NETA.CNM69
NETC.CNM01
NETC.CNM02
NETB.CNM20
NETB.CNM18
NETB.CNM16
*
FPCAT
-------OPS_MGMT
OPS_MGMT
ALERT
OPS_MGMT
OPS_MGMT
ALERT
PRIMARY FP
------------NETA.CNM99
NETA.CNM99
NETA.CNM99
NETA.CNM99
NETA.CNM99
NETA.CNM01
BACKUP FP
--------------NETB.CNM18
NETB.CNM18
NETB.CNM18
NETB.CNM18
NETC.CNM02
NETB.CNM18
During initialization, the SOC-MGR reads the entries in the configuration file. If
the focal point specified under PRIMARY FP is the same as the node on which you
are running, the SOC-MGR attempts to explicitly obtain the entry point into its
sphere of control.
For example, if the configuration file in the preceding example resides on
NETA.CNM99, the SOC-MGR on NETA.CNM99 attempts to obtain all of the entry
points listed under EPNAME, except NETB.CNM16, into its sphere of control.
Because the SOC-MGR ignores any statements where the primary focal point
specified is a node other than the node on which you are running, you can define
focal point-entry point relationships for your network in one configuration file, and
use the same file on all systems to start the sphere of control environment.
|
|
|
|
|
If you want information about...
Refer to...
How sphere of control works with
architectural focal points
IBM Tivoli NetView for z/OS Automation Guide
Forwarding Data to NetView Focal Points
The NetView program provides focal point support for the alert category that uses
a private NetView-to-NetView protocol. These focal point methods are unique to
the NetView program. With this NetView focal point support, the entry points and
focal points must all be NetView programs. The NetView focal point support
Chapter 10. Centralizing Operations
181
|
|
|
|
provides less function than the architectural focal point support because the
NetView focal point support cannot use the services that are provided with the
architectural focal point support. For example, NetView focal points cannot use the
services provided by the MS-CAPS application (including the SOC-MGR support).
|
For information about the NetView forwarding function, refer to IBM Tivoli
NetView for z/OS Automation Guide. After it is defined, an entry point NetView
program can forward data to its focal point over the LUC transport and a focal
point NetView program can receive data from its entry points over the LUC
transport.
Forwarding Alerts through LUC
Note: Consider using the LU6.2 method to forward alerts. For more information,
see “Forwarding Operations Management Data through LU 6.2” on page
175.
The LUC alert forwarding method is unique to the NetView program, and the
entry point and focal point must be NetView programs.
|
The alert forwarding function of the NetView program enables centralized network
management of distributed hosts. See the following information about setting up
alert focal points and distributed hosts for alert forwarding.
If you want information about...
Refer to...
Using the alert forwarding function
IBM Tivoli NetView for z/OS Automation Guide
Setting Up an LUC Alert Focal Point
To forward alerts from a distributed host, see “Setting Up a Distributed Host” on
page 183.
If you are using nonpersistent sessions, see “Establishing Nonpersistent Sessions”
on page 184.
DSICRTTD: Define enough DSRBOs to handle alert forwarding, cross-domain
communications, and distributed database retrieval. In DSICRTTD, DSRBO is a
DSTINIT parameter that specifies the projected number of concurrent user requests
for services from this data services task.
The value defined in the samples is 5, which allows one DSRBO for alert
forwarding and four DSRBOs for any cross-domain communication involving this
host or distributed database retrieval that is done from this host.
Note: The term any cross-domain communication involving this host means any
cross-domain sessions initiated by this host, or any cross-domain sessions
established with this host from another host over an LUC session.
To determine the number of DSRBOs that this alert focal point host needs, consider
the number of cross-domain conversations where this host can be involved at a
time, and the number of operators performing distributed database retrieval from
this host.
Change the value of the DSRBO to the number required for this host.
182
Installation: Configuring Additional Components
|
|
|
|
|
|
CNMSTYLE: When LUC.CTL=GLOBAL is specified in the CNMSTYLE member,
the NetView program ignores the specific LU names in the LUC.CNMTARG
statements. If you have coded LUC.CTL=SPECIFIC, use the CNMSTUSR or
CxxSTGEN member to add a LUC.CNMTARG statement for each domain with
which this host communicates using an LUC session. The following
LUC.CNMTARG statements are in the CNMSTYLE member. For information about
changing CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation:
Getting Started.
* LUC.CNMTARG.A=CNM01LUC
* LUC.CNMTARG.B=CNM02LUC YES
* LUC.CNMTARG.C=B01NVLUC NO
The second parameter on the LUC.CNMTARG statements overrides the default
value for persistent sessions specified in the LUC.PERSIST statement.
LUC conversations are used for alert forwarding and distributed database retrieval,
and hardware monitor and session monitor cross-domain conversations.
Setting Up a Distributed Host
If you are using nonpersistent sessions, see “Establishing Nonpersistent Sessions”
on page 184.
|
|
|
|
|
CNMSTYLE: Ensure that the NPDA.ALERTFWD statement is commented out in
the CNMSTYLE member or that it specifies NV-UNIQ. If you need to make
changes, use the CNMSTUSR or CxxSTGEN member; for information about
changing CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation:
Getting Started.
NPDA.ALERTFWD = NV-UNIQ
The NV-UNIQ option specifies that the NetView program forwards alerts over
LUC. This is the default when the NPDA.ALERTFWD statement is commented
out.
Alerts sent over LUC are forwarded only once, from the entry point (distributed
host) to the focal point. The focal point cannot forward these alerts again, neither
with LUC nor LU 6.2 alert forwarding. If you want the receiving focal point to
forward the alerts it receives from entry points, use LU 6.2 alert forwarding.
DSICRTTD: Define enough DSRBOs to handle alert forwarding, cross-domain
communications, and distributed database retrieval. The value defined in the
samples is 5, which allows one DSRBO for alert forwarding and four DSRBOs for
any cross-domain communication involving this host or distributed database
retrieval that is done from this host.
To determine the number of DSRBOs this distributed host needs, consider the
number of concurrent cross-domain conversations for this host.
Change the value of the DSRBO value to the number required for this host.
To specify the names of the primary and optional backup alert focal points,
uncomment and change the focal point names to match your configuration in the
following DEFFOCPT statement:
*
DEFFOCPT PRIMARY=CNM02LUC,TYPE=ALERT,BACKUP=CNM99LUC
Do not code the BACKUP operand in the DEFFOCPT statement if you are not
using a backup host.
Chapter 10. Centralizing Operations
183
Additional Considerations for Forwarding Alerts through LUC
Additional considerations for alert forwarding include:
v Hardware monitor
The hardware monitor tasks must be active to forward alerts. Enter the
STARTCNM NPDA command to begin the hardware monitor tasks if they are
not active.
The hardware monitor must be active on the focal point host for GMFHS to
provide the correct status for native resources. The hardware monitor must also
be active on every distributed system that supports service points used to collect
status for the native resources
v NV-UNIQ/LUC alert focal point
When an alert is forwarded with the NV-UNIQ/LUC method, the NetView
program first forwards it to the primary focal point. If unsuccessful, the NetView
program forwards it to the backup focal point. Note that the NetView program
first tries to establish a session with the primary focal point, regardless of
whether a persistent session with a backup focal point exists. If you do not
define a backup, or if the NetView program cannot forward the alert to either
the primary or backup focal point, only the entry point NetView logs the alert.
NV-UNIQ/LUC alert focal points do not support focal point nesting. When an
NV-UNIQ/LUC alert focal point receives alerts that were forwarded from a
NetView entry point using LUC, the NV-UNIQ/LUC alert focal point does not
forward such alerts again. Alerts that have been forwarded once with LUC
cannot be forwarded a second time. If you need intermediate node alert focal
points, consider using the SNA-MDS/LU 6.2 alert forwarding mechanism.
v Terminal access facility
Operators at the centralized host can perform problem determination by
accessing the remote host using terminal access facility (TAF) or cross-domain
function.
Additional TAF source LUs might be required, depending on the number of
operators that access remote hosts using the terminal access facility. For more
information, see “Defining the Terminal Access Facility” on page 186.
v Activating the links
If you use leased lines, activate the links between alert focal points and
distributed hosts. Refer to the VTAM library for additional information.
v CNM router
The CNM router must be active at distributed and alert focal point hosts for
LUC alert forwarding to work.
Establishing Nonpersistent Sessions
NetView LUC alert forwarding uses LUC sessions to forward alerts from
distributed hosts to the focal point and to perform distributed database retrieval.
Also, the hardware monitor and session monitor use LUC sessions to retrieve
cross-domain data. Nonpersistent session support gives you the option of
deactivating low-usage LUC sessions.
To define NetView-to-NetView LUC sessions as nonpersistent:
v Change the value of the session inactivity interval, or timeout interval, in the
NetView constants module, DSICTMOD, using CNMS0055. The NetView
program brings the session down when the interval of inactivity between
sessions exceeds this value.
Note: Reassemble DSICTMOD using CNMS0055 after making changes.
184
Installation: Configuring Additional Components
|
|
|
|
v In the CNMSTUSR or CxxSTGEN member, define the domains to which your
sessions are nonpersistent by coding the LUC.PERSIST statement, or specify NO
on the LUC.CNMTARG statement for these domains. For information about
changing CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation:
Getting Started.
You can define all LUC sessions as nonpersistent by using a global definition on
the DSTINIT statement.
You can also override this global name by individual domain on the CNMTARG
statement. When you define PERSIST=NO on an individual LU statement, the LUC
session from the host domain to the domain specified on the LU keyword is
nonpersistent, and is brought down if it is inactive for the number of seconds
specified in the timeout interval in DSICTMOD.
Examples
1. You are in domain CNM01, and want to establish a NetView-to-NetView LUC
session with domain CNM02 that is stopped after 10 seconds of inactivity.
Perform the following tasks:
v In CNMSTUSR or CxxSTGEN, specify:
LUC.CNMTARG.B=CNM02LUC NO
v In DSICTMOD, change the nonpersistent timeout interval from 0 to 10.
v Reassemble DSICTMOD using CNMS0055.
2. You want all sessions originating from this domain to be stopped after 30
seconds of inactivity. Perform the following tasks:
v In CNMSTUSR or CxxSTGEN, specify:
LUC.PERSIST=YES
v In DSICTMOD, change the nonpersistent timeout interval from 0 to 30.
v Reassemble DSICTMOD using CNMS0055.
Note: You can also specify YES on an individual LUC.CNMTARG statement,
overriding the LUC.PERSIST statement.
Defining Advanced Peer-to-Peer Networking Session
Configurations
The NetView session monitor provides information about Advanced Peer-to-Peer
Networking session configurations and session flow control data.
The location of the NetView program is very important in ensuring that all
Advanced Peer-to-Peer Networking data is collected and available for viewing.
Accomplish this by setting up LUC sessions.
LUC sessions must exist between endpoint nodes and interchange nodes within
the same network. Without these LUC sessions, the session monitor at the
endpoint node is missing some or all session configuration information. For
example, at a subarea end node without an LUC session to the interchange node,
the session monitor only has virtual route data, and does not have any RSCV data.
With an LUC session to the interchange node, the session monitor at this subarea
end node has RSCV data and virtual route data.
LUC sessions must also exist between interchange nodes in adjacent networks.
Without these LUC sessions, the session monitor at the interchange node cannot
get Advanced Peer-to-Peer Networking session configuration data from the
adjacent network.
Chapter 10. Centralizing Operations
185
If the session monitor is placed at an interchange node, LUC sessions to the end
nodes are not necessary because the interchange node has session configuration
data. With this placement of the NetView program, LUC sessions are needed only
to other interchange nodes in adjacent networks.
LUC sessions are necessary for obtaining session configuration and route data not
available in the local NetView program. Use the following general rules for setting
up LUC sessions:
v Set up an interchange node-to-interchange node (where interchange nodes are in
different networks) LUC session if your session monitor is at one of these
interchange nodes, and you need to see Advanced Peer-to-Peer Networking
session configuration data from the adjacent network for sessions passing
through the interchange node.
v Set up an interchange node-to-session end point node LUC session if your
session monitor is at the session end node, and you need to see Advanced
Peer-to-Peer Networking session configuration data from an end point in an
adjacent network. This situation also requires LUC sessions between the
interchange nodes.
v Set up an intermediate node-to-interchange node LUC session if your session
monitor is at an intermediate node that is not an interchange node or a session
end node. Since this intermediate node is not performing any boundary
functions, it receives no session awareness (SAW) data. The LUC session is
required for the SDOMAIN command.
If you want information about...
Refer to...
Data availability scenarios for Advanced
Peer-to-Peer Networking sessions
The IBM Tivoli NetView for z/OS Automation
Guide
Defining the Terminal Access Facility
The terminal access facility (TAF) lets an operator control any combination of
subsystems from one terminal. The operator does not have to log off or use a
separate terminal for each subsystem. The subsystem can be in the same domain or
in another domain.
You can have two types of TAF sessions: operator-control sessions and full-screen
sessions. Table 30 illustrates the subsystems you can control through the NetView
program using TAF, and the applicable session types.
Table 30. Subsystems Controlled Through TAF
Subsystem
Operator-control
Full-screen
CICS
X
X
IMS
X
X
HCF DPPX
X
X
HCF DPCX
X
TSO
X
DSX
X
NPM
X
SSP (THRU TSO)
X
TPF V2R4
186
Installation: Configuring Additional Components
X
X
In operator-control sessions, TAF acts like an SNA 3767 (LU type-1) terminal in
session with CICS/VS, IMS/VS, or HCF, except TAF ends the session when a
permanent error sense code (for example, 081C) is received. In this type of session,
any transaction you can enter from a 3767 terminal attached directly to one of
these subsystems can also be entered from the command facility panel.
Operator-control sessions are also called 3767-type sessions or LU1 sessions.
Note: Data entered during an operator-control session is not translated from
lowercase to uppercase.
In full-screen sessions, TAF acts like an SNA 3270 (LU type-2) terminal in session
with CICS, IMS, HCF Version 2 Release 1, TSO, or a cross-domain NetView system.
TAF lets full-screen applications operating on these subsystems use a NetView
panel. The NetView operator can also enter commands and data as though the
terminal were directly connected to the subsystem. Full-screen sessions are also
called 3270-type sessions or LU2 sessions.
Defining Additional Source LUs
A01APPLS (CNMS0013) defines five operator-control sessions and ten full-screen
sessions. The following definitions are the first three definitions for
operator-control sessions:
TAF01O00
*
TAF01O01
*
TAF01O02
*
APPL
MODETAB=AMODETAB,EAS=9,
DLOGMOD=M3767
STATOPT='TAFAPPL 000'
APPL MODETAB=AMODETAB,EAS=9,
DLOGMOD=M3767
STATOPT='TAFAPPL 001'
APPL MODETAB=AMODETAB,EAS=9,
DLOGMOD=M3767
STATOPT='TAFAPPL 002'
X
X
X
The following definitions are first three definitions for full-screen sessions:
TF01#000 APPL
MODETAB=AMODETAB,EAS=9,
DLOGMOD=M2SDLCNQ
*
STATOPT='DYNAMIC TAF 000'
TF01#001 APPL MODETAB=AMODETAB,EAS=9,
DLOGMOD=M2SDLCNQ
*
STATOPT='DYNAMIC TAF 001'
TF01#002 APPL MODETAB=AMODETAB,EAS=9,
DLOGMOD=M2SDLCNQ
*
STATOPT='DYNAMIC TAF 002'
X
X
X
The names (such as TAF01F00) are the SRCLU (secondary LU) names used to start
TAF sessions. The default SRCLU names used by the BFSESS and BOSESS
command lists are derived from the operator’s application (APPL) name. If you
want all of your operators to use these command lists without specifying an
SRCLU value, separate full-screen and operator-control SRCLU statements are
required for each operator. The derived name is TAF, followed by the fourth and
fifth characters of the APPL name, followed by O (operator-control) or F
(full-screen), followed by the seventh and eighth characters of the APPL name.
When an operator issues a BGNSESS command, an SRCLU is dynamically
allocated to that operator by a command list. Each operator requires a separate
SRCLU. If you need more than five concurrent operator control session users or
more than 10 concurrent full-screen session users, define additional SRCLUs. If you
code a password on an SRCLU APPL statement (PRTCT=nnnnn), the password
must be the same as the NetView password for that domain.
Chapter 10. Centralizing Operations
187
The MODETAB parameter points to AMODETAB (CNMS0001), the logmode table
for both operator-control and full-screen sessions. The DLOGMOD operand points
to an entry in AMODETAB (CNMS0001). Each entry is preceded by a description
of the device it supports. Make sure the DLOGMOD operands for your SRCLUs
point to the proper entries. To take advantage of graphics or color, use a logmode
that includes query. To take advantage of larger screens, the screen size values in
the TAF logmode must match the values specified in the logmode for the NetView
terminal. For IBM 3290 terminals, use logmode MSDLCQ. TAF sessions always use
SDLC logmode types, even on BSC terminals. For a complete list of logmode
entries, review AMODETAB (CNMS0001).
Before establishing a full-screen session, TAF checks the bind parameters that the
application sends. If the bind indicates that the application can write to an
alternative screen, the alternative screen size in the TAF bind must match the
alternative screen size in the NetView bind with the terminal.
For an operator-control session, the maximum RU size that can be received by TAF
from the subsystem is 16 Kilobytes.
When defining a TAF terminal to an application (for example, IMS/VS), take one
of the following actions:
v Use a bind that does not allow writing to an alternative screen.
v Use an alternative screen size to match the screen size of the NetView terminal
used to start the TAF session.
Accessing the Customer Information Control System Using TAF
If you are accessing the Customer Information Control System (CICS) using TAF,
define the SRCLUs to CICS.
An example of the parameters you can use to define an operator-control session to
CICS is:
DFHTCT TYPE=INITIAL,APPLID=CICS1,.....
DFHTCT TYPE=TERMINAL,
TRMIDNT=LU1,
TRMTYPE=3767,
RUSIZE=256,
BUFFER=256,
TIOAL=256,
.
.
.
NETNAME=TAF01O00,
(SRCLU)
.
.
.
X
X
X
X
X
X
X
Note: Each RUSIZE, BUFFER, and TIOAL cannot exceed 256 bytes for each
operator-control session. Refer to the CICS documentation for more
information.
An example you can use to define a full-screen session to CICS is:
DFHTCT TYPE=TERMINAL,
TRMIDNT=LU2,
TRMTYPE=LUTYPE2,
.
.
.
NETNAME=TAF01F00,
188
Installation: Configuring Additional Components
X
X
X
(SRCLU)
X
LOGMODE=M2SDLCNQ,
.
.
.
X
The NETNAME parameter refers to an SRCLU.
Accessing the Information Management System Using TAF
If you are accessing Information Management System (IMS) using TAF, define the
SRCLUs to IMS.
An example of the parameters you can use to define an operator-control session to
IMS is:
COMM APPLID=IMS1,......
TYPE UNITYPE=SLUTYPE1
TERMINAL NAME=TAF01O00
NAME TAF01O00
(APPLID definition)
(SRCLU OPCTL definition)
(VTAM LU/NODE name)
(IMS/VS LTERM name)
An example you can use to define a full-screen session to IMS is :
COMM
APPLID=IMS1,......
TYPE
UNITYPE=SLUTYPE2
TERMINAL NAME=TAF01F00,
MODEL=2,
FEAT=(NOCD),
OPTIONS=TRANRESP
NAME
TAF01F00
(APPLID definition)
(SRCLU FLSCN definition)
X
X
X
Note: If you specify a SEGSIZE or OUTBUF operand on the TYPE statement to
IMS, it must match the RU size in the logmode table defined to VTAM.
Accessing TSO Using TAF
If you are accessing TSO using TAF, you must know the LU name for TSO, which
is usually different from the ACB name. The LU name is the label on the first
(principal) APPL statement defining TSO to VTAM in your VTAMLST. Refer to
A01MVS (CNMS0047) for this label.
Note: Ensure the minor node names that define the TSO applications TSO001 TSO999 are a derivative of the major node name that you used to define the
TSO application statement.
Accessing CLSDST(PASS) Applications Using TAF
When using the BGNSESS command, operators need to use the application name
(LU name) when this name is different from the ACB name. Aliases cannot be used.
When an operator logs on to an application that uses CLSDST(PASS), the
application name is used by TAF to anticipate the LU name that is used for the
operator session. It is required that the application name be an initial substring of
the eventual operator session LU name. If, for example, CNMAA is an initial
substring of CNMAA001, an operator session with LU name CNMAA001 is
accepted by TAF for the application CNMAA. This pattern matches that used by
TSO, the NetView program, and certain other applications to derive LU names for
operator sessions. Use of long application names (especially eight character names)
limits your ability to use TAF.
Using TAF with Default LU Names
If TAF is to be used on LUs with default names, add APPL statements to define
the LUs available for use. These names must be defined if you want BGNSESS to
choose SRCLU values. The LU naming convention TFaa#nnn is shown here:
Chapter 10. Centralizing Operations
189
aa
are the last two characters of the domain ID
nnn
is a decimal number in the range of 000–999
Because BGNSESS selects LUs sequentially beginning with the lowest available
number nnn, only define the maximum number of LUs you expect to run
concurrently on your system for domain aa. For example, if your system has a
maximum of 50 LUs running with default names for domain NC, include APPL
statements defining TFNC#000 through TFNC#049.
The following example is an APPL statement for a VOST LU:
TF01#001 APPL
*
MODETAB=AMODETAB,EAS=9,
DLOGMOD=M2SDLCNQ
STATOPT='DYNAMIC TAF 001'
For additional examples, refer to CNMS0013 (A01APPLS).
190
Installation: Configuring Additional Components
X
Chapter 11. Defining Automation
This chapter includes the following topics that describe setting up NetView
automation facilities:
v “Updating the Automation Table”
v “Revising MVS Messages” on page 193
v “Enabling MVS Command Revision” on page 193
v “Enabling Workload Management to Manage the NetView Program” on page
194
v “Enabling SMF Record Type 30 Automation” on page 197
The Automated Operations Network (AON) facility is also used for automation.
For information, see “Defining AON” on page 43.
Updating the Automation Table
The automation table is installed and operational as part of the base NetView
installation. The following sections describe additional customization procedures
that you might consider for your environment.
If you want information about...
Refer to...
Automation table
IBM Tivoli NetView for z/OS Automation Guide
Defining Frame Relay and LMI Support
Frame relay defines the physical interface between customer equipment and
network connection point. NCP Version 6 accommodates the frame relay high
speed switching protocol. The NetView program can receive and act on the
information generated from NCP.
You can enable frame relay switching equipment (FRSE) and local management
interface (LMI) support by uncommenting the statements in the NetView
automation table, DSITBL01. The following statements allow alerts and frame relay
information to flow through the automation table.
Programming Interface information
*IF MSUSEG(0000) ¬= '' THEN
*
BEGIN;
*
IF MSUSEG (0000.52.07 7) = HEX('01') &
*
(MSUSEG (0000.52.0E) ¬= '' |
*
MSUSEG (0000.52.0F) ¬= '') THEN
***********************************************************************
* ADD OR CHANGE STATEMENTS BELOW TO WRITE YOUR OWN COMMAND PROCESSOR *
***********************************************************************
*
BEGIN;
*
END;
*
END;
*IF MSUSEG(1332) ¬= '' THEN
*
BEGIN;
*
IF MSUSEG (1332.52.07 7) = HEX('01') &
*
(MSUSEG (1332.52.0E) ¬= '' |
*
MSUSEG (1332.52.0F) ¬= '') THEN
***********************************************************************
© Copyright IBM Corp. 2001, 2009
191
* ADD OR CHANGE STATEMENTS BELOW TO WRITE YOUR OWN COMMAND PROCESSOR *
***********************************************************************
*
BEGIN;
*
END;
*
END;
End of Programming Interface information
To write your own network management application, write the logic in a
command processor. You can include logic in this command processor to create
objects in RODM for display by the NetView management console. This command
processor is not provided with the NetView program.
Note: Be sure to add a CMDDEF statement in the CNMCMD %INCLUDE member
CNMCMDU of DSIPARM for your command processor.
Handling Undeleted MVS Messages
You can handle MVS action messages. These messages are either WTOR messages
or messages that have a descriptor code that matches the setting of the
MVSPARM.ActionDescCodes statement in the CNMSTYLE member.
|
|
|
Defining VSAM Database Automation
The hardware monitor, 4700 support facility, session monitor, TCP/IP connection,
and save/restore databases can be automatically purged or reorganized. To do this,
use the following CNMSTYLE statements in the CNMSTUSR or CxxSTGEN
member, and enable VSAM database maintenance automation by removing the
asterisk at the beginning of the auxInitCmd statements. For information about
changing CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation:
Getting Started.
|
|
|
|
|
*auxInitCmd.DB1=DBINIT
*auxInitCmd.DB2=DBINIT
*auxInitCmd.DB3=DBINIT
*auxInitCmd.DB4=DBINIT
*auxInitCmd.DB5=DBINIT
* 04:00:00 1
NLDM NONE CYL 50
NPDA NONE CYL 50
TARA NONE CYL 50
SAVE NONE CYL 50
TCPCONN NONE CYL
50
50
50
50
50
Y PURGE 2 Y PURGE 2 02:00:00
Y PURGE 5 Y PURGE 5 02:30:00
Y REORG 0 Y REORG 0 03:00:00
Y REORG 0 Y REORG 0 03:30:00
50 Y PURGE 2 Y PURGE 2
1
1
1
1
To change the default values for these statements, follow the format specified in
the help for the DBINIT command list, CNME2009.
You can change the DSITBL01 processing. Search for DBFULL in the DSITBL01
member. The defaults shipped in the DSITBL01 member show that if the database
fills up twice in a 15-minute period, VSAM database automation is stopped. If the
database fills up twice in a 15-minute period, allocate more space for the database.
One suggestion is to make the time period greater than the time it takes to
reproduce the database using the DBFULL command, but less than the time it
takes to fill a newly-reproduced database.
Forwarding Alerts and Messages to the IBM Tivoli Enterprise
Console
The CNMSIHSA sample contains automation table statements that can be used to
forward alerts and messages to the NetView Event/Automation Service address
space. From there, the alerts and messages can be sent to the Tivoli Enterprise
Console.
To enable alerts and message routing:
v Customize the CNMSIHSA sample.
192
Installation: Configuring Additional Components
v Uncomment the following statement in the DSITBL01 member:
*%INCLUDE CNMSIHSA
If you want information about...
Refer to...
Enabling the Event/Automation Service
“Enabling the Event/Automation Service” on
page 210
Revising MVS Messages
You can use the message revision table to intercept MVS messages and make
changes to certain aspects, including the following aspects:
v Message text
v Color
v Route codes
v Descriptor codes
v Display and system log attributes
|
|
|
The message revision table is active even when the base NetView program is not
active, but the SSI address space is required. However, loading or querying the
message revision table or gathering statistics depends on the base NetView address
space being active.
|
|
|
|
Note that you can start message revision, if it is not already running, when the
base NetView program starts. To do that, use the SSI.ReviseTable statement in the
CNMSTUSR or CxxSTGEN member. For information about changing CNMSTYLE
statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
|
|
|
|
|
|
|
If you want information about...
Refer to...
Message revision table
IBM Tivoli NetView for z/OS Automation Guide
Enabling MVS Command Revision
Use the MVS command revision function to intercept MVS commands before they
are processed. Command sources include the MVS console and the NetView MVS
command. You can make changes to the command text, write a message to the
command issuer, and then run the command or suppress the command. You can
also transfer the command to the NetView program for more involved actions.
Configuring the NetView Program
|
|
|
|
|
A NetView operator ID is required for the autotask that manages MVS commands
that are directed to the NetView program. By default, the NetView program uses
the MVSCMDS operator ID. To use a different operator ID, update the following
statement in the CNMSTUSR or CxxSTGEN member:
|
|
For information about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started.
|
|
|
|
function.autotask.MVSCmdRevision=operid
Preparing the MVS System
The command revision exit uses the NetView subsystem interface (SSI). Ensure that
the NetView subsystem address space is started and that the command revision
exit is enabled.
Chapter 11. Defining Automation
193
To enable the command revision exit for processing on MVS:
1. Ensure the load module DSIRVCEX is in a load library in the MVS LINKLST
concatenation. If required, issue the following command to enable it:
|
|
|
|
|
|
|
|
|
F LLA,REFRESH
2. Update an MPFLSTxx member in PARMLIB by adding the following statement:
.CMD USEREXIT(DSIRVCEX)
To activate the change, issue the following command, where xx is the suffix of
the MPFLST member:
SET MPF=xx
Activating Command Revision
|
|
|
The command revision function requires the NetView SSI address space to be
active.
|
|
|
|
To activate the command revision function:
1. Create a command revision table or include UPON statements for command
revision in your existing message revision table.
2. Issue the REVISE command.
|
|
|
|
Note that you can start command revision, if it is not already running, when the
base NetView program starts. To do that, use the SSI.ReviseTable statement in the
CNMSTUSR or CxxSTGEN member. For information about changing CNMSTYLE
statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
||
If you want information about...
Refer to...
|
Creating the command revision table
IBM Tivoli NetView for z/OS Automation Guide
|
|
|
Using the REVISE CMD command
IBM Tivoli NetView for z/OS Command
Reference Volume 2 (O-Z)
|
Enabling Workload Management to Manage the NetView Program
You can optionally use the z/OS Workload Manager (WLM) to manage NetView
task performance in relation to other tasks and applications running on the system
or sysplex. The NetView program uses WLM to balance the workload between
NetView tasks. When WLM is enabled, NetView calls WLM during task
initialization and passes it the task information to allow WLM to assign it to the
appropriate service class. Each service class can be given different performance
goals and importance.
Preparing WLM for the NetView Environment
Before NetView support for WLM can be enabled, prepare WLM for the NetView
environment. Ensure that the following definitions are in place:
v Log on to TSO using your USERID that is authorized to update WLM policies
and open the Workload Manager dialog.
v Create a new definition that contains as a minimum:
Service Policy
Select option 1 on the Service Definition menu, specifying a service
policy name, and press Exit to save your changes.
194
Installation: Configuring Additional Components
Workload
Select option 2 on the Service Definition menu, specifying a workload
name, and press Exit to save your changes.
Automation (System Automation for z/OS) Service Class
Select option 1 on the Service Class Selection List menu. Specify a
service class name (for example NETVAUTO). This service class is used
for NetView automation tasks. Insert a new period. The following values
are examples:
– Processing velocity of 50%
– Importance of 1
Press Exit to save your changes.
Note: If you already have an STCHI service class defined, consider
using this class.
Default Service Class
Select option 4 on the Service Definition menu, specifying a service class
name (for example NETVDFLT). This service class is used for NetView
tasks that are not assigned to another service class. Insert a new period.
The following values are examples:
– Processing velocity of less than 50%
– Importance of 2
Press Exit to save your changes.
Note: If you already have an STCME service class defined, consider
using this class.
Classification Rule
Select option 6 on the Service Definition menu. This displays the
Subsystem Type Selection List for Rules menu. Specify a subsystem type
of NETV. From this menu, select action 1 to insert a rule and select
action 2 to insert sub-rules. Figure 15 on page 196 shows an example of
specifying rules and subrules. The following values are examples:
– Specify a default service class name as previously defined.
– Classify tasks by AOST type (rule) as the transaction class (TC), then
by System Automation for z/OS task names (subrule) as the user ID
(UI) value. For each task, specify the service name as previously
defined for System Automation for z/OS autotasks.
Press Exit to save your changes.
Chapter 11. Defining Automation
195
Subsystem-Type Xref Notes Options Help
-------------------------------------------------------------------------Modify Rules for the Subsystem Type
Row 1 to 18 of 18
Command ===> ____________________________________________ SCROLL ===> PAGE
Subsystem Type . : NETV
Fold qualifier names?
Description . . . NetView z/OS
Action codes:
C=Copy
D=Delete row
-------Qualifier------------Type
Name
Start
Action
____
____
A=After
B=Before
1
2
TC
UI
AOST
___
SA390*___
Y
(Y or N)
M=Move
R=Repeat
I=Insert rule
IS=Insert Sub-rule
More ===>
-------Class-------Service
Report
DEFAULTS: NETVDFLT
________
________
________
NETVAUTO
________
..
.
Figure 15. Inserting WLM Rules
Save and Activate the Definitions
Select Utilities on the Service Definition menu. Select option 1 to install
the definition, then select option 3 to activate the service policy.
Enabling WLM Support
After completing the MVS workload management definitions, use the WLM
statement in the CNMSTUSR or CxxSTGEN member. Remove the asterisk (*) from
the beginning of the statement, and change the SubSystemName value if necessary
to correspond to the system instance name specified in the WLM service
classification rules. For information about changing CNMSTYLE statements, see
IBM Tivoli NetView for z/OS Installation: Getting Started.
|
|
|
|
*WLM.SubSystemName=&DOMAIN
Verifying WLM Support
To verify that the NetView program is defined to MVS workload management, use
the LIST command or the LISTWLM command.
To display the WLM service class name of the WLM service class assigned to each
NetView subtask, enter:
LIST STATUS=TASKS WLM=YES
To display a windowed list of active NetView subtasks with their assigned WLM
service class name, enter:
LISTWLM
This list is sorted in ascending order by WLM service class name, task type, and
task ID.
To list the WLM service class for a single task, use the LIST command.
If WLM is not in use by the NetView program, the WLM service class is shown as
Not Available by the LIST and LISTWLM commands.
196
Installation: Configuring Additional Components
|
Enabling SMF Record Type 30 Automation
|
|
|
|
|
The MVS IEFACTRT SMF installation exit receives control from the system when a
job or job step ends, either normally or abnormally. The NetView program
provides an IEFACTRT sample exit (CNMSMF3E) that passes data across the PPI
to a receiver which issues a message that can be automated using the NetView
automation facilities.
|
|
|
|
To set up the CNMSMF3E sample as an IEFACTRT exit routine, requires the
following tasks:
v “Configuring the NetView program”
v “Preparing the MVS System” on page 198
||
If you want information about...
Refer to...
|
SMF record type 30 details
z/OS MVS System Management Facilities (SMF)
|
MVS dynamic exits
z/OS MVS Initialization and Tuning Reference
|
|
IEFACTFT exit details
z/OS MVS Installation Exits
|
|
|
|
|
|
|
Configuring the NetView program
Configuring the NetView program includes the following steps:
v “Configuring SMF30 statements in CNMSTYLE”
v
v
v
v
“Defining the AUTOSMF3 autotask”
“Defining the DSISMF3F command”
“Defining automated processing for message BNH874I” on page 198
“Updating the automation table” on page 198
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Configuring SMF30 statements in CNMSTYLE
|
|
|
|
Defining the AUTOSMF3 autotask
|
|
|
|
|
Defining the DSISMF3F command
Review the following CNMSTYLE statements and make any necessary updates to
the CNMSTUSR or CxxSTGEN member:
************************************************************************
*
SMF 30 record receiver
*
* Uncomment the following (and, optionally, supply a preferred
* operator ID) to start the SMF 30 record receiver function.
*
************************************************************************
* function.autotask.SMF30 = AUTOSMF3
*
AUTOTASK.?SMF30.Console = *NONE*
AUTOTASK.?SMF30.InitCmd = CNMSMF3R
The supplied DSIOPF member in the DSIPARM data set includes a definition for
the AUTOSMF3 autotask. Ensure that this definition is included in your DSIOPF
member.
The CNMCMENT member in the DSIPARM data set includes a definition for the
DSISMF3F command. This command is driven by the CNMSMF3R PPI receiver to
format the BNH874I message. Ensure that this definition is included in your
CNMCMENT member.
Chapter 11. Defining Automation
197
|
|
|
You can either use the shipped DSISMF3F command to format the BNH874I
message or you can customize the CNMSMF3F sample and then link it as
DSISMF3F.
|
|
|
Defining automated processing for message BNH874I
|
|
|
|
Updating the automation table
The CNMSMF3A sample command list is issued by the automation table when the
BNH874I message is issued. Update this command list to take appropriate action.
The DSITBL01 member in the DSIPARM data set includes sample automation to
issue the CNMSMF3A command when a BNH874I message is received. Ensure that
similar automation statements are included in your automation table.
Preparing the MVS System
|
Preparing the MVS System includes the following tasks:
v “Assemble and Link-Edit the CNMSMF3E Exit”
v “Update SYS1.PARMLIB Library”
|
|
|
|
|
|
|
|
|
Assemble and Link-Edit the CNMSMF3E Exit
|
|
Update SYS1.PARMLIB Library
The CNMSMF3E sample is an IEFACTRT SMF exit that processes type 30 SMF
records and sends them across the PPI to the NetView program for automation.
After making any necessary changes, assemble and link-edit the CNMSMF3E exit
into a library in the LNKLST concatenation. Refresh the LNKLST to dynamically
activate the new exit.
Make the following updates to the SYS1.PARMLIB library:
1. Update the SMFPRMxx member:
v Ensure that the TYPE operand of the SYS specification includes record type
30, for example:
|
|
|
|
|
|
|
SYS(TYPE(30,37,38,39))
v Ensure that the EXITS operand of the SYS (system-wide) specification
includes IEFACTRT, for example:
SYS(EXITS(IEFACTRT,IEFUJI,IEFU83,IEFU84,IEFU85))
|
|
|
|
More than one exit routine can be defined for the IEFACTRT exit, so there can
be more than one EXIT statement for the SYS.IEFACTRT exit.
2. Update the PROGxx member to include the CNMSMF3E exit, for example:
||
If you want information about...
Refer to...
|
|
|
Updating SYS1.PARMLIB library
IBM Tivoli NetView for z/OS Installation:
Getting Started
|
Verifying the SMF 30 processing
EXIT ADD EXITNAME(SYS.IEFACTRT) MODNAME(CNMSMF3E)
To verify that the SMF 30 processing is functioning correctly:
|
|
|
|
1. Issue the DISPPI command to verify that the CNMSMFR receiver is active, for
example:
DISPPI RCVRID=CNMSMFR
During CNMSTYLE processing, the CNMSMF3R command is run by the
AUTOSMF3 autotask. This starts the CNMSMFR receiver.
|
|
198
Installation: Configuring Additional Components
|
|
|
|
|
|
|
2. End a job or job steps such that SMF type 30 records (subtype 4 or 5) are
generated.
3. Examine the NetView log for the following messages:
v CNM493I messages that includes the CNMSMF3A command, indicating that
the automation table entry was processed
v BNH874I messages after submitting a job or starting a started task that
ended with completion codes
Chapter 11. Defining Automation
199
200
Installation: Configuring Additional Components
Chapter 12. Setting Up UNIX System Services for the NetView
Program
|
The NetView program uses z/OS UNIX System Services for the following
functions:
v UNIX command server
v Some AON/TCP functions
v Event/Automation Service
v Event correlation and, optionally, the Common Event Infrastructure
If you are not planning to use NetView z/OS UNIX functions, continue with
Chapter 13, “Enabling the NetView Program with Other Products,” on page 219.
Table 31 lists the tasks necessary to prepare UNIX for z/OS to enable NetView
functions.
Table 31. Tasks to Prepare UNIX System Services
Task
UNIX
Command
Server
Modify UNIX system
services parameters
X
Update security
X
Add or change
environment variables
X
Event /
Automation
Service
X
AON/TCP
Functions
Event
Correlation
X
X
X
X
X
X
TCP/IP Considerations
Each of the applications that uses z/OS UNIX System Services is a z/OS UNIX
sockets application. Any z/OS sockets application needs to reference TCP/IP
configuration data. The method of accessing this data is defined by the z/OS
version of TCP/IP that is running. Refer to the z/OS Communications Server IP
Configuration Guide for general information about how z/OS UNIX sockets
applications interact with TCP/IP. This book also discusses how a z/OS UNIX
sockets application:
v Gains affinity to a TCP/IP stack
v Resolves names to IP addresses
v Finds required TCP/IP configuration data sets
The following sections show examples of using the UNIX System Services
RESOLVER_CONFIG environment variable for resolving the TCP/IP configuration
data.
Notes:
1. Using RESOLVER_CONFIG is recommended for the following reasons:
v In a multiple-stack environment, you can specify which TCP/IP stack the
NetView program is to use.
v RESOLVER_CONFIG is higher in the search order and easier to change than,
for example, the SYSTCPD DD statement.
© Copyright IBM Corp. 2001, 2009
201
2. RESOLVER_CONFIG use applies only to the UNIX command server and the
Event/Automation Service, particularly when the Event/Automation Service is
started in the UNIX System Services shell and not in the NetView base.
A commented SYSTCPD DD statement is provided in the Event/Automation
Service startup procedure to identify the location of TCP/IP configuration data. A
SYSTCPD statement is not required for the Event/Automation Services if you use
the RESOLVER_CONFIG UNIX System Services environment variable. Refer to the
z/OS Communications Server IP Configuration Guide for information about how a
z/OS UNIX sockets application uses the SYSTCPD DD statement, and determine
whether you need to use a SYSTCPD statement in the Event/Automation Service
startup procedure.
Notes:
1. For all of the z/OS UNIX sockets applications provided with the NetView
program, the stack affinity is determined by UNIX System Services
configuration definitions. Refer to the z/OS Communications Server IP
Configuration Guide for considerations for multiple instances of TCP/IP.
2. The UNIX command server is an indirect z/OS UNIX sockets application. The
application does not use z/OS UNIX sockets. Some of the UNIX System
Services commands that are run using the command server are z/OS UNIX
sockets commands. Because of this, these commands require access to TCP/IP
configuration data.
3. The AON/TCP application uses the UNIX command server to process
commands. As a result, this application is also an indirect z/OS UNIX sockets
application. However, part of the AON/TCP application runs in the NetView
address space. This part of the AON/TCP application is an z/OS sockets
application. The NetView part of the AON/TCP application gets its stack
affinity from configuration statements in the NetView configuration member
CNMPOLCY in DSIPARM.
4. In a z/OS UNIX INET (single stack) environment, the socket application
program is always associated with the single TCP/IP stack. In the z/OS UNIX
Common INET (CINET) environment, your application is associated with
multiple TCP/IP stacks unless the application specifically associates with a
particular stack.
Some NetView socket applications do not bind themselves to a particular stack
in a multi-stack environment. If you require that NetView socket applications
(such as the native SNMP command) or user-written socket applications
running in the NetView address space be bound to a particular stack in a
CINET environment, consider establishing affinity using the following method.
The BPXTCAFF program can be used to bind affinity to a stack of your choice.
To do this, the BPTXTCAFF program must run prior to the program that
initializes the NetView address space. One way of doing this is to add this
statement in the NetView startup JCL just prior to the statement used to start
NetView:
|
//STEP0
EXEC PGM=BPXTCAFF,PARM=MYSTACK
where the PARM= parameter is a pointer to the stack to which you want to
establish affinity. This example shows what the startup JCL might look like
after the step is added. This example is for reference only.
.
.
.
//**************************************************************
//STEP0
EXEC PGM=BPXTCAFF,PARM=MYSTACK
//**************************************************************
//*
202
Installation: Configuring Additional Components
//* PROCEDURE TO START-UP THE NETVIEW APPLICATIONS.
//* THE REGION SIZE IS 4096K IN THIS SAMPLE AS SPECIFIED IN THE
//* REG PARAMETER ABOVE. TO CALCULATE THE CORRECT REGION SIZE
//* FOR YOUR NETWORK, PLEASE REFERENCE THE NETVIEW STORAGE ESTIM
//* MANUAL.
//*
//*
//NETVIEW EXEC PGM=&PROG,TIME=1440,
//
REGION=&REG.K,
//
PARM=(&BFSZ.K,&SLSZ,'&DOMAIN','&DOMAINPW','&ARM',
//
'&SUBSYM','&NV2I'),
//
DPRTY=(13,13)
.
.
.
|
|
|
|
|
|
|
|
|
For additional information about BPXTCAFF and CINET environments, see
UNIX System Services Planning.
5. For the Event/Automation Service (E/AS), to request transport affinity when
multiple transports are used, set the _BPXK_SETIBMOPT_TRANSPORT
environment variable to the name of the preferred transport before starting
E/AS. This variable can also be set in the PARM= parameter of the E/AS
started procedure. For example, the following PARM sets up transport affinity
to TCPIP03:
//STEP1
//
//
EXEC PGM=&PROG,TIME=1440,REGION=&REG,
PARM=('ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP03")',
'/INITFILE=&INITFILE')
Modifying UNIX System Services System Parameters
Member BPXPRMxx in SYS1.PARMLIB contains system values and the file
information required for the startup of z/OS UNIX System Services. This member
contains MOUNT statements that cause the specified HFS-type data set to be
mounted during z/OS UNIX System Services initialization.
If necessary, add a MOUNT statement in member BPXPRMxx for the target HFS
data set:
MOUNT FILESYSTEM('<HFS Pathname>')
TYPE(HFS)
MODE(READ)
MOUNTPOINT('<PathPrefix>/usr/lpp/netview')
Note: You might have already added this statement during NetView SMP/E
installation.
<HFS Pathname> is the name of the target HFS data set that was allocated during
NetView SMP/E installation and was used to install the NetView z/OS UNIX
System Services code into HFS directories. If you did not allocate this target HFS
data set, you do not need to add this MOUNT statement to your BPXPRMxx
member. If you specified a <PathPrefix> during the installation of NetView (for
example, /service/), specify the full path name to your mount point directory as
your MOUNTPOINT value (for example: ‘/service/usr/lpp/netview’).
Note: The steps in the NetView program directory direct you to mount your target
HFS data set in read/write (RDWR) mode. After completing the steps in the
program directory, mount your target HFS data set in read (READ) mode to
protect the data installed in your NetView HFS directories.
Chapter 12. Setting Up UNIX System Services for the NetView Program
203
To ensure that sufficient resources are available for all UNIX applications,
including Java applications, consider the following settings in BPXPRMxx:
MAXTHREADS(10000)
MAXTHREADTASKS(5000)
MAXASSIZE(2147483647)
Examine the settings for the MAXPROCSYS and MAXPROCUSER statements in
the BPXPRMxx member in the SYS1.PARMLIB data set. The MAXPROCSYS
statement specifies the maximum number of processes that can be active at the
same time. The MAXPROCUSER statement specifies the maximum number of
processes with a single UID that are allowed to be active at the same time. The
number of TCP/IP-related processes that are spawned as a result of NetView
commands can exceed the system-supplied defaults for these UNIX System
Services settings. These limits might need to be increased. The settings can be
temporarily increased by using the SETOMVS command and remain in effect until
the next IPL.
If you want information about...
Refer to...
BPXPRMxx
z/OS library
Creating Directories and Copying MIB Source Files
The CNMSJ032 member (CNMSAMP) performs the following actions:
v Create directories in your z/OS UNIX System Services environment
v Copy MIB source files to a working directory
v Copy properties files and sample rule files for the event correlation service
Review the comments in the job profile and make any changes before running this
job. This job must be run by a userid that has superuser authority (for example,
ROOT).
Run the CNMSJ032 job. CNMSJ032 creates the following directories:
v /etc/netview/v5r4
v /etc/netview/mibs
v /tmp/netview/v5r4
v /etc/netview/v5r4/properties
v /etc/netview/v5r4/usercode
v /tmp/netview/v5r4/logs
v /var/netview/v5r4/rulefiles
MIB source files are then copied from the /usr/lpp/tcpip/samples directory to the
/etc/netview/mibs directory. You can also place other MIB source files in
/etc/netview/mibs.
CNMSJ032 also copies the event correlation properties file to /etc/netview/v5r4/
properties and the sample rules file to /var/netview/v5r4/rulefiles. You can edit
the properties file to customize the correlation engine. For information about the
properties file statements, refer to IBM Tivoli NetView for z/OS Administration
Reference.
Verify the return codes:
v A return code of 0 indicates that the MIB source files were copied successfully.
v A return code of 4 indicates that the MIB source file or files already exist in the
/etc/netview/mibs directory. Because of that, the MIB source file or files were
204
Installation: Configuring Additional Components
not copied. Review the held output report (SYSTSPRT) to see which MIB source
files were not copied and manually migrate the files to the current release of the
NetView program.
v If you receive a return code greater than 4, check the z/OS library for
information to correct the problem and resubmit the job.
|
|
|
Note: If you upgrade the z/OS system to V1.10 or later, run the CNMSJ032 sample
to copy the proper MIB files to the /etc/netview/mibs directory. For more
information, see the CNMSJ032 sample.
Updating UNIX System Services Environment Variables
Table 32 shows the z/OS UNIX System Services environment variables that need to
be added or modified for the UNIX command server and AON/TCP functions.
Table 32. z/OS UNIX System Services Environment Variables by NetView Function
Environment Variable
Value1
PATH
/usr/lpp/netview/v5r4/bin
RESOLVER_CONFIG
//'TCPIP.INIT(TCPDATA)'
UNIX
Command
Server
AON/TCP
Functions
X
X
X
Notes:
1. Can vary by installation.
Notes:
1. PathPrefix/usr/lpp/netview/v5r4 is the default directory into which the
NetView program is installed.
If you specify a different value during installation for PathPrefix (for example,
/service), make the appropriate substitutions to the example path names.
2. For performance considerations, avoid using the STEPLIB environment
variable.
For more information, refer to the z/OS library.
The correlation engine and Common Event Infrastructure can function without
requiring any environment variables to be set. However, if needed for your
installation, you can define environment variables that override default values of
the locations of the correlation engine code, properties files, rules files, and log
files. Environment variables can be set in UNIX System Services initialization files
if the correlation engine is started as a daemon or started from a shell, or in the
CNMSJZCE job if you start the correlation engine from JCL. Table 33 shows the
environment variables that you can set.
Table 33. Environment Variables That Can be Set in UNIX System Services Initialization
Files
Environment
Variable
Value
LOGPATH
The path to the directory that contains the log file. The default value is
/tmp/netview/v5r4/logs/.
RULEPATH
The path to the directory that contains the XML rule file. The default
value is /var/netview/v5r4/rulefiles/.
Chapter 12. Setting Up UNIX System Services for the NetView Program
205
Table 33. Environment Variables That Can be Set in UNIX System Services Initialization
Files (continued)
Environment
Variable
Value
PROPPATH
The path to the directory that contains the property files for the
correlation engine and logging service. The default value is
/etc/netview/v5r4/properties/.
PROPFILE
The name of the correlation engine properties files. The default value is
correlator.properties.
RULEFILE
The name of the rule file to load. The default value is znvrules.xml.
LOGFILE
The name of the log file. The default value is nvcorrelation.log.
INSTPATH
The path to the directory that contains the correlation engine code. The
default value is /usr/lpp/netview/v5r4/.
USERPATH
The path to the directory that contains user-compiled Java code for
customized actions. The default value is /etc/netview/v5r4/usercode/.
The variables can be set in the CNMJZCE startup JCL in a manner similar to the
variables for the UNIX command server, described in “Specifying NetView z/OS
UNIX Environment Variables” on page 207. The STDENV DD statement can be
used to define the variables in-stream (as is done in the shipped sample), or else
the DD statement can refer to a z/OS data set name or to a partitioned data set.
Refer to the CNMSJZCE sample for more details. When starting the correlation
engine from a shell or as a daemon, the environment variables can be set in a
manner described in “Managing NetView z/OS UNIX Functions from z/OS
UNIX” on page 207.
Some of the environment variables correspond to properties that are contained in
the properties files that are used by the correlation engine. These are the location
and name of the rule file and the log file. The following order of precedence is
used:
v Properties file
v Environment variables
v Defaults
The properties file that is used by the correlation engine can be passed as a
parameter on the startup script. If the parameter is supplied, it overrides the value
of the PROPPATH and PROPFILE environment variables.
The logging service that is used by the correlation engine has its own properties
file, specified by the JLOG.CONFIGURATION property in the properties file. This
file contains entries for the default logging level and the location and name of the
log file. The LevelLogger section has the following entry:
logger.level.level=
The level value can be specified to control the number of log entries created.
Generally, more entries are generated to aid in debugging problems. Levels are
arranged in a hierarchy. The level specified is the lowest level logged. All higher
levels are also logged. The following values are valid for level, in order of severity:
v FATAL
v ERROR
v WARN
v INFO
v DEBUG_MIN
v DEBUG_MID
v DEBUG_MAX
206
Installation: Configuring Additional Components
The default value is INFO. Information entries indicate the status of the correlation
engine and the connections being made. DEBUG_MIN logs entries that show the
flow of events into and out of the correlation engine. DEBUG_MID traces module
entry/exit and includes information about the events being sent and received.
DEBUG_MAX traces additional internal processing in the engine, such as parsing
of events.
The logging level in use can be changed by issuing the CORRSERV LOGLEVEL
command from the NetView program. Edit the JLOG.CONFIGURATION file only
to change the default level.
You can also use the JLOG.CONFIGURATION file to specify the name and location
of the log file. The following entries are relevant:
handler.file.filedir=
handler.file.filename=
These are shipped as $(LOGPATH) and $(LOGFILE). The values are substituted for
the values of the LOGPATH and LOGFILE environment variables, if set, or to the
defaults of /tmp/netview/v5r4/logs/ and nvcorrelation.log if the environment
variables are not set. If you want to use a non-default value and do not want to set
environment variables, these values can be changed in the configuration file.
Specifying NetView z/OS UNIX Environment Variables
To manage NetView z/OS UNIX functions directly from the NetView program,
add and modify the environment specification in the STDENV DD statement in the
UNIX command server JCL sample CNMSJUNX or CNMSSUNX.
You can define the STDENV DD in the UNIX command server JCL in several
ways:
v z/OS UNIX path name, for example:
//STDENV
//
DD PATH=/etc/netview/v5r4/stdenv,PATHOPTS=ORDONLY,
PATHMODE=SIRWXU
v Instream data within the JCL, for example:
//STDENV
DD DATA
PATH=/bin:/usr/lpp/netview/v5r4/bin:/usr/lpp/tcpip/bin
RESOLVER_CONFIG=//'TCPIP.INIT(TCPDATA)'
.
.
.
/*
Note: Environment variable definitions are limited to 72 bytes in length in JCL.
v z/OS data set name or partitioned data set (PDS) member name. The data set
can be a fixed or variable block data set with a record length large enough to
accommodate the largest environment variable definitions. For example:
//STDENV
DD DSNAME=NETVIEW.DSIPARM(STDENV),DISP=SHR
Managing NetView z/OS UNIX Functions from z/OS UNIX
To manage NetView z/OS UNIX functions from z/OS UNIX, add or modify the
environment variables in z/OS UNIX. The environment variables are defined in
one of the following profiles:
1. The UNIX user profiles, for the user who is starting and stopping functions
2. The default UNIX profile (for example /etc/profile)
Variables defined in this way can be exported in the following way:
export name=value
Chapter 12. Setting Up UNIX System Services for the NetView Program
207
or
name=value
export name
Enabling the UNIX Command Server
The UNIX command server enables UNIX commands to be entered from the
NetView command line and returns the output of these commands to the NetView
console. The UNIX commands entered from the NetView program are run in the
UNIX System Services environment of the z/OS operating system.
Note: UID(0) is not required.
Defining the UNIX Command Server
To enable the running of UNIX for z/OS commands from the NetView program, a
dedicated PPI receiver (CNMEUNIX) is needed to receive commands and data
from the NetView program. A server process running in a UNIX for z/OS address
space waits on this PPI receiver for incoming commands and data.
CNMEUNIX runs as a UNIX for z/OS kernel process. The UNIX command server
consists of three parts that must be installed in the UNIX hierarchical file system
(HFS). The default directory into which the installation installs the parts is
<PathPrefix>/usr/lpp/netview/v5r4/bin.
Setting a region size for the UNIX command server of 0MB allows the UNIX
command server to access all available memory. System-defined installation exits
might limit this amount. If you receive an out-of-memory condition for the UNIX
command server address space, adjust the installation exit values.
If the UNIX command server is started as a submitted job, ensure that the
CNMSJUNX sample job is contained in a DSIPARM data set. If the UNIX
command server is started as a started task, ensure that the CNMSSUNX sample
job is copied into a data set defined in the IEFJOBS or IEFPDSI concatenation of
master JCL, for example, SYS1.PROCLIB. This is required because CNMSSUNX
contains a job statement. Also ensure that the sample z/OS START command
CNMSUNXS is contained in a DSIPARM data set. For more information about
specifying whether the UNIX command server runs as a submitted job or as a
started task, refer to the online help for the DEFAULTS STRTSERV command.
Before you start a UNIX command server, you can customize the samples that are
provided with the NetView program to fit your environment. If the SCNMLNKN
data set is not defined as part of the LNKLST concatenation, you must include a
STEPLIB DD statement for it in the UNIX command server JCL. When a START
UNIXSERV command is issued, the NetView program issues an MVS START
command (if DEFAULTS STRTSERV is set to STRTPROC) or submits a job (if
DEFAULTS STRTSERV is set to SBMTJOB). For a started task, member
CNMSUNXS contains the MVS START command that is used to start the
procedure or job specified in the START UNIXSERV command. For a submitted
job, the member specified on the MEM keyword in the START UNIXSERV
command is submitted as an MVS job.
|
|
|
|
Member CNMSUNXS or the member containing the submitted JCL, for example,
CNMSJUNX, can contain specific variables for which the NetView program
performs substitutions before the task is started or the job is submitted. These
variables have names that begin with an ampersand (&) followed by lowercase
208
Installation: Configuring Additional Components
letters and end with a period (.). You can specify any of these substitution
variables to customize how your UNIX command server is started. The following
list describes these variables:
&sprcnm.
The member name containing the JCL that is to be started or submitted.
This value is the value of the MEM keyword on the START UNIXSERV
command
v For a started task, if MEM is not specified, CNMSSUNX is used. This
variable is specified in sample CNMSUNXS as the procedure or job to
start.
v For a submitted job, if MEM is not specified, CNMSJUNX is used. This
variable is not specified in sample CNMSJUNX because it is the same as
the sample name.
&jobname.
The name to be used on the JOB statement on a submitted job. This value
is always set to CNMEUNIX.
v For a started task, this variable is not specified in sample CNMSUNXS
because it does not apply to the MVS START command.
v For a submitted job, this variable is not specified in sample CNMSJUNX
because the name is always set to CNMEUNIX.
&userid.
The TSO user ID under whose authority the started task or submitted job
runs. To easily identify which user ID the task or job is running for, the
JOBNAME (for start) or the step name (for submit) specifies this name. The
value is always set to CNMEUNIX.
v For a started task, this variable is specified in sample CNMSUNXS as
the value for the JOBNAME keyword on the MVS START command.
v For a submitted job, this variable is not specified in sample CNMSJUNX.
&ppiname.
The receiver name used for communication between the server and the
NetView program across the PPI. The value is always set to CNMEUNIX.
v For a started task, this variable is not specified in sample CNMSUNXS
because the PPI name is always CNMEUNIX.
v For a submitted job, this variable is not specified in sample CNMSJUNX
because the PPI name is always CNMEUNIX.
If your installation is a RACF controlled environment, there are additional RACF
requirements. For more information, refer to the IBM Tivoli NetView for
z/OS Security Reference.
Starting the UNIX Command Server
To start the UNIX command server from the NetView program, enter the following
command from the command facility:
START UNIXSERV=*
If multiple versions of the UNIX command server JCL are required, the optional
MEM parameter can be specified on the START UNIXSERV command. You can use
the MEM parameter to specify members other than the CNMSJUNX for submitted
jobs or CNMSSUNX for started tasks.
After starting UNIXSERV, you receive the following message:
Chapter 12. Setting Up UNIX System Services for the NetView Program
209
DSI633I START COMMAND SUCCESSFULLY COMPLETED
If you want information about...
Refer to...
START command
NetView online help for NCCF START
Issuing UNIX for z/OS commands from the
NetView program
NetView online help for PIPE UNIX
Security considerations for the UNIX
command server
IBM Tivoli NetView for z/OS Security Reference
Starting from UNIX for z/OS
Because the UNIX command server runs as a UNIX daemon, you can start the
UNIX command server from UNIX for z/OS. For example, you can use the
following command:
_BPX_JOBNAME='CNMEUNIX' /usr/lpp/netview/v5r4/bin/cnmeunix > /tmp/nvunix.out 2>&1&
Assigning a value for _BPX_JOBNAME enables the named address space to be
displayed on an SDSF active tasks display or when a D A command is issued from
an z/OS console.
Note: You can add this command to a UNIX for z/OS initialization script file such
as /etc/rc.
The directory containing the UNIX command server code needs to be included in
the PATH environment variable (set up in /etc/profile).
UNIX command server diagnostic information is written primarily to stdout but,
under certain circumstances, messages can be written to stderr. The diagnostic
information written to stdout contains the error data that is returned in the
secondary output stream of the PIPE UNIX stage and might include the name of
the UNIX service that failed.
Verifying that the UNIX Command Server is Active
Regardless of how the UNIX command server is started, verify that the UNIX
command server is running by entering the DISPPI command from the NetView
command facility. The CNMEUNIX PPI receiver needs to exist and be active as
shown in the following example:
DWO948I
DWO949I
DWO950I
DWO952I
DWO951I
DWO951I
DWO951I
DWO951I
DWO951I
DWO951I
DWO968I
RECEIVER RECEIVER
IDENTITY STATUS
-------- -------NETVALRT INACTIVE
NETVRCV
ACTIVE
:
:
:
:
CNMEUNIX ACTIVE
:
:
:
:
END OF DISPLAY
BUFFER
QUEUED
TOTAL
STORAGE
LIMIT
BUFFERS
BUFFERS
ALLOCATED
---------- ---------- ---------- ---------1000
0
0
0
500
0
24
0
1000
0
3
0
Enabling the Event/Automation Service
The Event/Automation Service serves as a gateway for event data between the
IBM Tivoli NetView for z/OS management environment, the Tivoli management
region environment, and SNMP trap managers. With this gateway function, you
can manage all network events from the management platform of your choice.
210
Installation: Configuring Additional Components
Event/Automation Service runs as a separate z/OS address space. The default
startup procedure is IHSAEVNT.
|
|
|
|
|
Event/Automation Service consists of the following services that convert event
data into different formats and forward the data to event management tools:
v The alert adapter and message adapter services convert IBM Tivoli NetView for
z/OS alerts and messages into Tivoli Enterprise Console events before
forwarding the event data to a Tivoli Enterprise Console event console in the
Tivoli management region. As a result, all network events can be managed from
a Tivoli Enterprise Console event console. For more information about the Tivoli
Enterprise Console event console, refer to the Tivoli Enterprise Console library.
v The confirmed alert and message adapter services convert alerts and messages
into Tivoli Enterprise Console events and forward them to an event server. The
event server then replies with a confirmation that indicates acceptance of the
Tivoli Enterprise Console event.
v The alert-to-trap service converts IBM Tivoli NetView for z/OS alerts into SNMP
traps before forwarding the trap data to an SNMP manager. Event/Automation
Service performs the function of an SNMP subagent, and sends the converted
alert data to an SNMP agent for eventual forwarding to an SNMP manager.
v The event receiver service converts events that arrive from a Tivoli management
region into alerts before forwarding the alert to the IBM Tivoli NetView for
z/OS program through the Alert Receiver PPI mailbox. As a result, all network
events can be managed from the hardware monitor.
v The trap-to-alert service converts SNMP traps that arrive from SNMP managers
into alerts before forwarding the alert to IBM Tivoli NetView for z/OS through
the Alert Receiver PPI mailbox.
The Event/Automation Service is an event source for the Tivoli Enterprise Console.
The default installation of the Tivoli Enterprise Console allows for the reception
and display of events that are forwarded by the Event/Automation Service. Refer
to the Tivoli Enterprise Console documentation for additional configuration
information relating to the reception and display of events from event sources.
Preparing the z/OS Host Components
The Event/Automation Service can be configured to start from either the z/OS
system console using job IHSAEVNT, or from a UNIX System Service command
shell.
Preparing to Start as a Job
|
|
To start the Event/Automation Service from a job, follow these steps:
1. Copy the IHSAEVNT sample from NETVIEW.V5R4M0.CNMSAMP to a system
procedure library.
2. Allocate a data set to contain your configuration parameters. The DCB
attributes must match those of the NETVIEW.V5R4M0.SCNMUXCL data set.
3. For any services that you plan to use (see “Getting Ready to Start the
Event/Automation Service” on page 213), copy the members that you need to
change from the SCNMUXCL data set to the data set allocated in the previous
step.
4. If you use an SAF product, such as RACF, define the procedure IHSAEVNT to
have superuser authority in the OMVS segment of the security product.
Chapter 12. Setting Up UNIX System Services for the NetView Program
211
Preparing to Start in a UNIX System Service Command Shell
To configure the Event/Automation Service to be started from a UNIX system
service command shell, follow these steps:
1. Add NETVIEW.V5R4M0.CNMLINK to the STEPLIB environment variable for
your shell session.
2. Create a file in the Hierarchical File System (HFS) named IHSAC000 that has
run permission and has the sticky bit on.
|
|
3. For any services that you plan to use (see “Getting Ready to Start the
Event/Automation Service” on page 213), copy the members that you need to
change from the SCNMUXCL data set to the HFS directory /etc/netview/v5r4.
Rename the PDS members to their corresponding names as shown in Table 34.
These names are case sensitive.
4. Copy the IHSAMSG1 file from the NETVIEW.V5R4M0.SDUIMSG1 data set to
the /usr/lpp/netview/msg/C HFS directory. Rename this member to its
corresponding name as shown in Table 34. This name is case sensitive.
|
|
|
Table 34 describes the locations of the configuration parameters for the components
of the Event/Automation Service.
Table 34. Event/Automation Service configuration files
|
|
|
|
|
|
|
|
212
SCNMUXCL Member Name HFS Configuration File
Name
Used By
IHSAINIT
global_init.conf
All services for global
initialization
IHSAACDS
alert_adpt.cds
Alert adapter service
IHSABCDS
confirm_alert_adpt.cds
Confirmed alert adapter
service
IHSAACFG
alert_adpt.conf
Alert adapter service
IHSABCFG
confirm_alert_adpt.conf
Confirmed alert adapter
service
IHSAATCF
alert_trap.conf
Alert-to-trap service
IHSALCDS
alert_trap.cds
Alert-to-trap service
IHSAECDS
event_rcv.cds
Event receiver service
IHSAECFG
event_rcv.conf
Event receiver service
IHSAMCFG
message_adpt.conf
Message adapter service
IHSANCFG
confirm_message_adpt.conf
Confirmed message adapter
service
IHSAMFMT
message_adpt.fmt
Message adapter service
IHSANFMT
confirm_message_adpt.fmt
Confirmed message adapter
service
IHSATALL
trap_alert_all.cds
Trap-to-alert service
IHSATCDS
trap_alert.cds
Trap-to-alert service
IHSATCFG
trap_alert.conf
Trap-to-alert service
IHSATMSM
trap_alert_msm.cds
Trap-to-alert service
IHSATUSR
trap_alert_user.cds
Trap-to-alert service
IHSAMSG1
ihsamsg1
All services
Installation: Configuring Additional Components
Getting Ready to Start the Event/Automation Service
|
|
|
|
|
The Event/Automation Service is composed of the following services:
v Alert adapter service
v Message adapter service
v Confirmed alert adapter service
v
v
v
v
Confirmed message adapter service
Event receiver service
Trap-to-alert service
Alert-to-trap service
By default, the alert adapter, message adapter, and event receiver services are
started when you start the Event/Automation Service. You can prevent these
services from starting automatically, or you can allow the confirmed alert adapter,
confirmed message adapter, trap-to-alert and alert-to-trap service to start
automatically. Refer to the NOSTART statement in the IBM Tivoli NetView for
z/OS Administration Reference for information about how to prevent a service of the
Event/Automation Service from starting.
To make changes, modify the Event/Automation Service procedure IHSAEVNT.
Add the user data set that you created for modifying configuration files from the
SCNMUXCL data set to the IHSSMP3 DD statement in the procedure. If you do
not have the LE/370 libraries defined in your system concatenation, uncomment
the LE/370 statement in the procedure and set it to the correct data set.
Getting Ready to Start the Alert Adapter Service
You must provide a Tivoli Enterprise Console server location for the Alert Adapter
service. This is done using the ServerLocation and optionally the ServerPort
statements in the alert adapter configuration file (SCNMUXCL IHSAACFG
member or alert_adpt.conf HFS file). Refer to the ServerLocation and ServerPort
statements in the IBM Tivoli NetView for z/OS Administration Reference for
information about how to provide the Tivoli Enterprise Console server information.
Note: If your ServerPort statement is set such that PortMapper is required, make
sure that the Portmapper service is running on the Tivoli Enterprise Console
server at the IP location specified on the ServerLocation statement. By
default, this statement is set to require the Portmapper service.
The routing of alerts from the NetView address space to the Event/Automation
Service alert adapter service is disabled by default. To route NetView alerts to the
Event/Automation Service alert adapter service, the hardware monitor TECROUTE
and AREC filters must be set to PASS. This allows all alerts to be routed to the
Event/Automation Service alert adapter service. For information about setting
hardware monitor filters, refer to the SRFILTER command in the NetView online
help or IBM Tivoli NetView for z/OS Command Reference Volume 1 (A-N).
The alert adapter service has a number of other settings that can be customized.
For information about customizing the alert adapter service, refer to IBM Tivoli
NetView for z/OS Customization Guide.
Getting Ready to Start the Message Adapter Service
You must provide a Tivoli Enterprise Console server location for the Message
Adapter service. This is done using the ServerLocation and optionally the
ServerPort statements in the message adapter configuration file (SCNMUXCL
IHSAMCFG member or message_adpt.conf HFS file). Refer to the ServerLocation
Chapter 12. Setting Up UNIX System Services for the NetView Program
213
and ServerPort statements in the IBM Tivoli NetView for z/OS Administration
Reference for information about how to provide the Tivoli Enterprise Console server
information.
Note: If your ServerPort statement is set such that PortMapper is required, make
sure that the Portmapper service is running on the Tivoli Enterprise Console
server at the IP location specified on the ServerLocation statement. By
default, this statement is set to require the Portmapper service.
The routing of messages from the NetView address space to the Event/Automation
Service is disabled by default. To route NetView messages to the
Event/Automation Service, add statements to your automation table to select
specific messages and route them using a PIPE stage. The CNMSIHSA sample
member contains automation table statements to route messages.
To enable message routing from the NetView program, customize the CNMSIHSA
sample to route any messages that you want. Then, uncomment the statement that
includes CNMSIHSA in the DSITBL01 automation table. For more information
about customizing CNMSIHSA, refer to IBM Tivoli NetView for z/OS Automation
Guide.
The message adapter service has a number of other settings that can be
customized. For information about how to further customize the message adapter
service, refer to IBM Tivoli NetView for z/OS Customization Guide.
|
|
|
|
|
|
|
Getting Ready to Start the Confirmed Alert Adapter Service
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The routing of alerts from the NetView address space to the Event/Automation
Service confirmed alert adapter service is disabled by default. To route NetView
alerts to the Event/Automation Service confirmed alert adapter service, follow
these steps:
v Set the hardware monitor AREC, ESREC, and TECROUTE filters to PASS. This
allows all alerts to be routed to the Event/Automation Service confirmed alert
adapter service. For information about setting hardware monitor filters, refer to
the SRFILTER command in the NetView online help or IBM Tivoli NetView for
z/OS Command Reference Volume 1 (A-N).
v Use NetView automation to drive a command that uses the PIPE PPI stage with
the TECRTCFM keyword to forward alert data to the Event/Automation Service.
The Event/Automation Service can then send the data to the confirmed alert
adapter. For example automation statements, see the CNMSIHSA sample. For
examples on how to add user-specified data to the alert data to be passed to the
confirmed alert adapter, see the CNMEALUS sample.
|
|
|
The confirmed alert adapter service has a number of other settings that can be
customized. For information about customizing the confirmed alert adapter service,
refer to IBM Tivoli NetView for z/OS Customization Guide.
|
|
|
Getting Ready to Start the Confirmed Message Adapter Service
You must provide an event server location for the confirmed alert adapter service.
This is done using the ServerLocation and optionally the ServerPort statements in
the confirmed alert adapter configuration file (SCNMUXCL member IHSABCFG or
HFS file confirm_alert_adpt.conf). Refer to the ServerLocation and ServerPort
statements in the IBM Tivoli NetView for z/OS Administration Reference for
information about how to provide an event server location.
You must provide an event server location for the confirmed message adapter
service. This is done using the ServerLocation and optionally the ServerPort
214
Installation: Configuring Additional Components
|
|
|
|
|
statements in the confirmed message adapter configuration file (SCNMUXCL
member IHSANCFG or HFS file confirm_message_adpt.conf). Refer to the
ServerLocation and ServerPort statements in the IBM Tivoli NetView for
z/OS Administration Reference for information about how to provide an event server
location.
|
|
|
|
|
|
The routing of messages from the NetView address space to the Event/Automation
Service is disabled by default. To route NetView messages to the
Event/Automation Service, add statements to your automation table to select
specific messages and route them using the PIPE PPI stage with the TECRTCFM
keyword. Sample member CNMSIHSA contains automation table statements to
route messages.
|
|
|
|
|
To enable message routing from the NetView program, customize samples
CNMSIHSA and CNMEMSUS to route any messages that you want. Then,
uncomment the statement that includes CNMSIHSA in the DSITBL01 automation
table. For more information about customizing CNMSIHSA and CNMEMSUS, refer
to IBM Tivoli NetView for z/OS Automation Guide.
|
|
|
The confirmed message adapter service has a number of other settings that can be
customized. For information about how to further customize the confirmed
message adapter service, refer to IBM Tivoli NetView for z/OS Customization Guide.
Getting Ready to Start the Event Receiver Service
The event receiver service functions properly without customization. However, this
service has a number of settings that can be customized using the event receiver
configuration file (SCNMUXCL member IHSAECFG or HFS file event_rcv.conf).
For information about how to customize the event receiver service, refer to IBM
Tivoli NetView for z/OS Customization Guide.
Notes:
1. If your UsePortmapper statement is set such that PortMapper is required,
ensure that the Portmapper service is running on the z/OS host where the
Event/Automation Service is running. By default, this statement is set to
require the Portmapper service.
2. If you are using TCP/IP to communicate between Tivoli NetView for z/OS and
the MultiSystem Manager agent, a port number must be explicitly assigned to
the event receiver service using the PortNumber statement in the event receiver
configuration file. Specify the same port number on the event receiver
PortNumber statement and the ALERTDESTINATIONPORT parameter in the
MSMNFNT.INI file on the service point computer where the MultiSystem
Manager agent is running.
Getting Ready to Start the Trap-to-Alert Service
The trap-to-alert service functions properly without further customization.
However, this service has a number of other settings that can be customized using
the trap-to-alert configuration file (SCNMUXCL member IHSATCFG or HFS file
trap_alert.conf). For information about customizing the trap-to-alert service, refer to
IBM Tivoli NetView for z/OS Customization Guide.
Note: If you have an SNMP Manager that uses port 162 on the same system as the
Event/Automation Services, customize the trap-to-alert service to use
another port or use the sample trap forwarding daemon provided with the
Event/Automation Service to forward traps. For information about how to
use the sample trap forwarding daemon, refer to the IBM Tivoli NetView for
z/OS Customization Guide.
Chapter 12. Setting Up UNIX System Services for the NetView Program
215
Getting Ready to Start the Alert-to-Trap Service
The alert-to-trap service functions properly without further customization.
However, this service has a number of other settings that can be customized using
the alert-to-trap configuration file (SCNMUXCL member IHSAATCF or HFS file
alert_trap.conf). For information about customizing the trap-to-alert service, refer to
IBM Tivoli NetView for z/OS Customization Guide.
Because the alert-to-trap service functions as an SNMP subagent, the SNMP agent
provided with TCP/IP must be started and properly configured so that the
alert-to-trap service can pass traps to the agent. Refer to your TCP/IP
documentation for information about how to enable the SNMP agent daemon.
The routing of alerts from the NetView address space to the Event/Automation
Service alert-to-trap service is disabled by default. To route NetView alerts to the
alert-to-trap service, set the hardware monitor TRAPROUTE and AREC filters to
PASS. This allows all alerts to be routed to the alert-to-trap service. For information
about setting hardware monitor filters, refer to the SRFILTER command in the
NetView online help or the IBM Tivoli NetView for z/OS Command Reference Volume
1 (A-N).
Starting the Event/Automation Service
You can start the Event/Automation Service from an z/OS system console using
job IHSAEVNT , or from a UNIX System Service command shell.
Starting the Event/Automation Service Using Job IHSAEVNT
To start the Event/Automation Service, enter the following command at the system
console:
S IHSAEVNT
Messages similar to those in Figure 16 are displayed.
IHS0075I
IHS0124I
IHS0124I
IHS0124I
Event Automation Services started. Subtask initialization is in progress for IHSATEC
Event Receiver task initialization complete.
Alert Adapter task initialization complete.
Message Adapter task initialization complete.
Figure 16. Messages for Starting the Event/Automation Service
The other Event/Automation Service services are not automatically started when
the Event/Automation Service is started. For information about how to start and
stop individual services when the Event/Automation Services is started, refer to
the NOSTART statement in the IBM Tivoli NetView for z/OS Administration
Reference.
|
|
|
|
|
Starting the Event/Automation Service Using the UNIX System
Services Command Shell
After performing the required steps listed previously for starting the
Event/Automation Service from a UNIX System Services command shell, start the
Event/Automation Service by entering IHSAC000 from the command shell:
You see messages similar to those in Figure 17 on page 217.
216
Installation: Configuring Additional Components
IHS0075I
IHS0124I
IHS0124I
IHS0124I
Event Automation Services started. Subtask initialization is in progress for IHSATEC
Event Receiver task initialization complete.
Alert Adapter task initialization complete.
Message Adapter task initialization complete.
Figure 17. Messages for Starting the Event/Automation Service from a UNIX System Services Command Shell
|
|
|
|
|
The other Event/Automation Service services are not automatically started when
the Event/Automation Service is started. For information about how to start and
stop individual services when the Event/Automation Services is started, refer to
the NOSTART statement in the IBM Tivoli NetView for z/OS Administration
Reference.
Enabling Event Correlation and the Common Event Infrastructure
Event correlation is a NetView function that runs under UNIX Systems Services
outside the NetView address space. It works with the NetView automation table to
correlate NetView messages and alerts that are mapped to events. You can use
correlation to relate and process multiple messages or MSUs for automation. For
more information, see the IBM Tivoli NetView for z/OS Automation Guide.
The connection between the correlation engine and the NetView program is made
through TCP/IP sockets. If a large volume of events are to be sent for correlation,
consider optimizing local socket performance in Communications Server and your
TCP/IP setup.
The correlation engine is also used by the Common Event Infrastructure. Common
Base Events pass through the correlation engine before being stored in the
Common Event Infrastructure database or when the NetView program receives
events from the database. This is true regardless of whether the events are
correlated.
Use of the Common Event Infrastructure is optional. The correlation engine can
function regardless of whether the Common Event Infrastructure is being used. If
the Common Event Infrastructure is not being used, the correlation engine log
might include an entry for a failure to establish a socket connection to the
Common Event Infrastructure client. If the Common Event Infrastructure and
Common Base Event support are not being used, this error message can be
ignored.
Installing the Event Correlation Engine
Use the CNMSJ032 sample job to configure the directories used by the correlation
engine. For more information, refer to “Creating Directories and Copying MIB
Source Files” on page 204. When the job runs successfully, you can customize the
properties and rule files. For information about the properties file statements, see
the IBM Tivoli NetView for z/OS Administration Reference.
Installing the Common Event Infrastructure Server and Client
|
|
|
The NetView program includes Common Event Infrastructure (CEI) client code,
which must be installed in a WebSphere client environment. The client must be
installed and started to enable the Common Event Infrastructure.
|
When the client is installed, a ceiClient.properties file is installed in the same
directory as the startup batch file or script. This file needs to be configured to
identify the TCP/IP host where the correlation engine is running, the WebSphere
Chapter 12. Setting Up UNIX System Services for the NetView Program
217
Application Server host where the CEI server is running, and the ports that the
client listens on for connections from the NetView program and to establish its
own connection with the NetView program. For more information, see the
ceiClient.properties file.
|
Creating the Event Correlation Engine Rules
By default, a sample rule file is placed in the following location:
/var/netview/v5r4/rulefiles
You can customize this file as needed. You can also specify another rule file or
directory location by changing the RULEFILE property in the properties file or by
setting the RULEPATH and RULEFILE environment variables. For the rule
statement syntax, see the IBM Tivoli NetView for z/OS Automation Guide.
Updating the XML Correlation Rules
You can use the CORRSERV command to refresh the rule definitions. For more
information, see the online help for the CORRSERV command.
Starting the Correlation Engine
Before you start the correlation engine, verify that the Java program is installed on
the UNIX System Services, the system path is updated so that the system can find
the Java command, and the rule definitions are in place.
You can start the correlation engine in the following ways:
v At system initialization. To do this, modify the /etc/rc file to start the
corrstart.sh shell file under /usr/lpp/netview/v5r4/bin. The following
statement is an example:
_BPX_JOBNAME='NVCORRD' /usr/lpp/netview/v5r4/bin/corrstart.sh &
v From a z/OS system console by running the CNMSJZCE job
v From an OMVS ID by running the UNIX System Service command shell
corrstart.sh
After you start the correlation engine, start the DSICORSV task.
When the correlation engine has started, you can use the NetView CORRSERV
command to control the correlation engine, including stopping it. For more
information about the CORRSERV command, see IBM Tivoli NetView for
z/OS Command Reference Volume 1 (A-N).
If you stop the correlation engine, you can start it again using the CNMSJZCE job
or from the command shell corrstart.sh.
Besides the correlation engine, the NetView Common Event Infrastructure client
must be started to store or receive events from the Common Event Infrastructure
database. The client runs in a WebSphere client environment. The easiest location
to run the client is under the WebSphere server where the Common Event
Infrastructure is installed. To start the client, switch to the directory where the
client is installed and run the startClient batch file or run the shell script,
depending on whether the client is running on Windows or on a
UNIX/AIX/Linux environment. To stop the client, end the batch or shell script for
the client by pressing CTL-C from the window where the client was started.
218
Installation: Configuring Additional Components
Chapter 13. Enabling the NetView Program with Other
Products
The following products complement the NetView program to provide a
comprehensive set of enterprise management functions:
v “Tivoli Management Regions”
v “System Automation for z/OS”
v “Tivoli NetView Program” on page 221
v “Tivoli Business Systems Manager” on page 222
v “Tivoli OMEGAMON XE Products” on page 222
If the installation of any complementary products includes command definitions,
these command definitions must now be placed in CNMCMDO. Their format
matches the command definitions in CNMCMD.
Tivoli Management Regions
A Tivoli management region is a logical representation of a group of resources that
share a common policy region and are managed by a single server. Policy regions
are logical groups that are based on the shared characteristics of their members.
For example, a region might be geographically based (all the systems in Detroit) or
application-based (all the users of a set of software applications) or use any other
common defining principle. Policy regions mask the operating system and
hardware differences of resources when a management function is running across
Tivoli management regions.
The NetView hardware monitor component can display events related to Tivoli
management region resources, and the Tivoli Enterprise Console can integrate
information about resources managed by the NetView for z/OS program with
information about Tivoli management region resources.
When used with the MultiSystem Manager Tivoli management region agent, the
MultiSystem Manager component of the NetView for z/OS program can gather
topology and status information about the resources managed by the Tivoli
management region. This information is then stored in RODM and can be
displayed graphically using the NetView management console.
If you want information about...
Refer to...
Setting up the interface between the Tivoli
management region and the NetView
program
“Enabling the Event/Automation Service” on
page 210
MultiSystem Manager Tivoli management
region agent
IBM Tivoli NetView for z/OS Installation:
Configuring Graphical Components
System Automation for z/OS
System Automation for z/OS is a comprehensive automation product for z/OS
applications. It centralizes operations such as initial microcode load (IML), initial
program load (IPL), automation of system resources, and reconfiguring local or
remote target systems, of z/OS processors and operating systems. With this
© Copyright IBM Corp. 2001, 2009
219
platform, an operator at a focal point host can control and monitor multiple target
systems such as z/OS, VM, VSE, and TPF, concurrently.
As shipped by the NetView program, System Automation for z/OS is disabled. To
enable System Automation, take these actions:
v Copy the TOWER statement from the CNMSTYLE member to the CNMSTUSR
or CxxSTGEN member, and remove the asterisk (*) that precedes the SA tower
on the statement. For information about changing CNMSTYLE statements, see
IBM Tivoli NetView for z/OS Installation: Getting Started.
v If you are running System Automation for OS/390 Version 2.2 or earlier, apply
APAR OA10721. This APAR provides System Automation for OS/390 command
definitions in member INGCMD.
v If you are running AON and System Automation for z/OS in the same NetView
address space, see “Enabling Workload Management to Manage the NetView
Program” on page 194.
v If you configure System Automation for z/OS to start system services (for
example, TCP/IP and UNIX System Services), consider that some of these
services might be required by AON initialization. You can use the
COMMON.EZLINITDELAY statement in the CNMSTUSR or CxxSTGEN
member to specify the amount of time to wait before initializing AON. This
enables System Automation for z/OS to start the system services that might also
be required by AON. For information about changing CNMSTYLE statements,
see IBM Tivoli NetView for z/OS Installation: Getting Started.
|
|
|
|
|
|
|
|
If you want information about...
Refer to...
System Automation for z/OS
System Automation for z/OS library or to
http://www.ibm.com/servers/eserver/
zseries/software/sa/.
System Operations
The system operations component can automate console operations by monitoring
messages received from z/OS subsystems and related products, comparing them to
statements in the NetView automation table, and initiating actions when a match is
found.
CICS Automation
CICS Automation provides monitoring and control all of the local and remote CICS
regions within your organization. The interface simplifies the CICS monitor and
control tasks, so that these tasks can be performed across systems from a single
operator session. For example, an operator can obtain detailed information about
CICS subsystems and manually initiate startup or shutdown processes for a
subsystem, a group of subsystems, or all of the subsystems on a specified NetView
domain.
IMS Automation
IMS Automation provides a single-point-of-control for IMS startup, shutdown,
recovery, and extended recovery facility (XRF) takeover operations, based on the
automation environment supported by the system operations component. IMS
automation provides functions that are not available in the NetView program, IMS,
or the system operations component, resulting in a more comprehensive
automation capability than is possible with these products individually.
220
Installation: Configuring Additional Components
The benefits of IMS are multiplied in an XRF IMS environment where the purpose
is to maintain an alternate IMS subsystem. In such an environment, IMS switches
its workload to another set of available resources (takeover) quickly and with
minimal disruption. This results in reduced IMS outages (scheduled and
unscheduled), enhanced operator productivity, and reduced error potential.
DB2 Automation
DB2 automation can increase database availability by monitoring IMS and CICS
connections and critical DB2 events. You can use a command interface to stop
threads, start DB2 in maintenance mode, and manage tablespaces. Samples are
provided to define a DB2 subsystem to System Automation for z/OS and to enable
generic critical event monitoring.
TWS Automation
TWS Automation is an extension of System Automation for z/OS that uses the
strengths of the NetView for z/OS, System Automation for z/OS, and Tivoli
Workload Scheduler programs to provide greatly expanded job processing,
scheduling, monitoring, and alert notification.
Processor Operations
The processor operations component centralizes operations of System z processors
and operating systems, such as initial microcode load (IML), recycling operating
systems (IPL), automation, and reconfiguring local or remote target systems. The
processor operations component is used to start or stop systems; the system
operations component is used to manage applications that run on the systems that
the processor operations component starts or stops.
With the processor operations component, an operator at a focal point host can
control and monitor multiple target systems, such as MVS, VM, VSE, and TPF,
concurrently. In a parallel sysplex environment, the processor operations
component supports the coupling facility at a target system, both with coupling
links and with the Integrated Coupling Migration Facility.
The processor operations component provides built-in automation that can be
extended by user-written automation routines and by its integration with the
system operations component on the operator views of the System Automation for
z/OS graphical interface.
I/O Operations
I/O Operations inherits and enhances the functions of ESCON® Manager. With I/O
Operations, you can make multisystem operational changes to channels, ESCON
Directors, and devices while protecting access to critical system resources. I/O
Operations provides NetView Management Console monitoring of I/O resource
exceptions and text and multisystem graphical displays of active I/O
configurations. I/O Operations also supports interaction with ESCON Manager
and the level of function provided in that product.
Tivoli NetView Program
The Tivoli NetView program is a comprehensive management tool for
heterogeneous, multivendor devices on TCP/IP networks. When used with the
MultiSystem Manager IP agent, the MultiSystem Manager component of the
NetView for z/OS program can gather topology and status information about the
Chapter 13. Enabling the NetView Program with Other Products
221
resources managed by the Tivoli NetView program. This information is then stored
in RODM and can be displayed graphically using the NetView Management
Console.
Tivoli Business Systems Manager
IBM Tivoli Business Systems Manager is an enterprise management product that
monitors the data processing resources that are critical to a business application.
Mission-critical business systems typically span host and distributed environments;
include many interconnected application components, both commercial and
custom; and rely on diverse middleware, databases, and supporting platforms.
Tivoli Business Systems Manager provides end-to-end business systems
management to organize related components and give business context to
management decisions. A unique, configurable business system view enables
management and control of the multiple integrated software components required
to deliver a specific business service. The product also shows and allows the
manipulation of the relationships between applications, so that you can more easily
detect inefficiencies or diagnose problems in critical business systems.
If you want information about...
Refer to...
Configuring the NetView management
console for the Tivoli Business Systems
Manager Console
IBM Tivoli NetView for z/OS Installation:
Configuring Graphical Components
Tivoli OMEGAMON XE Products
The NetView program interoperates with IBM Tivoli OMEGAMON XE products
through the NetView Web application and the NetView for z/OS Enterprise
Management Agent. For installation and configuration information, see IBM Tivoli
NetView for z/OS Installation: Configuring the Tivoli NetView for z/OS Enterprise
Management Agent.
|
|
From the NetView Web application, you can retrieve performance data for a
TCP/IP connection from OMEGAMON XE for Mainframe Networks using the
Tivoli Enterprise Monitoring Server Web Services interface.
The NetView for z/OS Enterprise Management Agent provides linking to
OMEGAMON XE product workspaces. If you have the appropriate OMEGAMON
XE products installed and configured, the links between the NetView for z/OS
Enterprise Management Agent workspaces and the OMEGAMON XE workspaces
are operable. For more information, see IBM Tivoli NetView for z/OS Installation:
Configuring the Tivoli NetView for z/OS Enterprise Management Agent.
IBM Tivoli Change and Configuration Management Database
A NetView for z/OS Discovery Library Adapter (DLA) for TCP/IP extracts data
about TCP/IP resources and relationships from the NetView for z/OS RODM data
cache and sends the managed resource information to IBM Tivoli Change and
Configuration Management Database (IBM Tivoli CCMDB) to be stored in the
configuration management database (CMDB). Source data for distributed and
zSeries® TCP/IP resources and connections is collected by the NetView for z/OS
MultiSystem Manager IP agent.
222
Installation: Configuring Additional Components
NetView TCP/IP data in the configuration management database enables
applications such as IBM Tivoli CCMDB to locate resources discovered by other
providers, such as an FTP server in a TCP/IP network. Operators and network
analysts can use this resource correlation to solve outages and improve
configuration and change management. Of particular value is the correlation
between TCP/IP z/OS resources discovered by the NetView for z/OS program
and z/OS resources discovered by the z/OS DLA.
For more information about the NetView for z/OS Discovery Library Adapter
(DLA) for TCP/IP, see “Enabling the NetView for z/OS Discovery Library
Adapter” on page 124.
Chapter 13. Enabling the NetView Program with Other Products
223
224
Installation: Configuring Additional Components
Chapter 14. Installing the Globalization Feature
|
If you ordered this feature, follow the steps in this chapter to perform these tasks:
v Install a globalization feature
v Create translated messages
Note: If you use REXX in the NetView environment, the language specified for
TSO/E REXX must be compatible with the language specified for the
NetView program.
|
|
|
|
|
|
Installing a Globalization Feature
To install a globalization feature:
1. Load the globalization feature from the distribution tape following the
instructions in the NetView program directory.
2. If you are migrating from a release of the NetView program prior to NetView
for OS/390 V1.2, the CNMMSJPN member might be named JAPANMSG.
3. If you customized or added messages, add a %INCLUDE statement for your
customized member at the beginning of the CNMTRMSG member, or move
your translations into the CNMTRUSR member.
4. If you are migrating from a previous release of the NetView program and you
customized messages, or you want to modify the V5R4 messages to reflect your
customization, see “Creating Translated Messages” on page 226 for more
information about how to modify NetView messages.
5. Use the following statement in the CNMSTUSR or CxxSTGEN member. For
information about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started.
transTbl = DSIKANJI
The NetView program supports EBCDIC or Kanji character sets. All the
NetView workstations in the domain must support the character set you decide
to use. Multilingual support is not available. Coexistence of Japanese and
English domains is allowed. The NetView program sends messages in English
between these domains.
|
The system console supports only the EBCDIC character set. So, do not
generate Japanese messages or commands that are sent to the system console in
user-written command lists, command processors, installation exit routines, or
subtasks. This restriction also applies to messages sent to the NetView program
through the subsystem interface. The NetView program does not support
Japanese characters in its command strings, regardless of origin.
If you are using REXX in the NetView environment, the language specified for
TSO/E REXX must be compatible with the language specified for the NetView
program.
To enable the printing of a non-EBCDIC character set, CNMPRT (CNMSJM04)
must have a TRANSTBL statement that specifies the same module that is
specified in the TRANSTBL statement in the CNMSTYLE member.
|
6. To begin the Japanese-support automatically when the NetView program is
started, use the following statement in the CNMSTUSR or CxxSTGEN member,
© Copyright IBM Corp. 2001, 2009
225
and remove the asterisk (*) from the beginning of the statement. For
information about changing CNMSTYLE statements, see IBM Tivoli NetView for
z/OS Installation: Getting Started.
|
|
|
transMember = CNMTRMSG
In the CNMTRMSG member, uncomment the CNMMSJPN member in the
following way:
"* %INCLUDE CNMMSJPN"
to
"%INCLUDE CNMMSJPN"
Note: If the TRANSMSG statement is not included in the CNMSTYLE member,
a NetView operator can issue the command to initiate message
translation.
|
7. Add the 939 code page to the GMFHS data model DUIFSTRC.
Global_NLS_Parameters_Class
MANAGED OBJECT CLASS;
PARENT IS Presentation_Services_Global_Parameters_Class;
ATTRLIST
CodePage
INTEGER INIT(939);
END;
OP Global_NLS_Parameters_Class.CodePage
HAS_SUBFIELD NOTIFY;
View_Parent_Class
MANAGED OBJECT CLASS;
Note: You can only place characters from code pages other than 037 in the
DisplayResourceName field for any data model you create within
RODM. For example, you can change the following line in sample
DUIFSNET:
"DisplayResourceName ::=[CHARVAR] 'V01LG01';"
You can change it in the following way:
"DisplayResourceName ::=[CHARVAR] 'some_other_characters';"
Remember to add the shift-out and shift-in characters around any DBCS
characters you add.
8. To enable GMFHS to send Japanese text to a NetView management console
topology console, add the following parameter to member DUIGINIT:
JAPANESE=ON
Creating Translated Messages
To create your own messages for translation:
1. Create your translation entries in the CNMTRUSR sample.
Note: When a message is processed that has a message ID that starts with an
asterisk (*), the asterisk is ignored during table comparisons and is
always copied to the first character in the translated message. For
example, an entry for EZL501I is matched by message IDs EZL501I and
*EZL501I, and the resulting output is the same except for the leading
asterisk in the second case.
2. Uncomment the %INCLUDE statement for the CNMTRUSR sample in the
CNMTRMSG sample.
Note: To modify any messages that are supplied by IBM, copy them to the
beginning of the CNMTRUSR sample, and then modify the copies. If two
or more messages have the same identifier, the NetView program uses
|
226
Installation: Configuring Additional Components
the message that occurs first in the member. The rules for writing your
own message translations are listed in “Formatting of Globalization
Feature Message Skeletons.”
|
3. Issue the following command from the command facility to do syntax checking
and load the message translations:
TRANSMSG MEMBER=CNMTRMSG
|
|
|
4. Use the following statement in the CNMSTUSR or CxxSTGEN member.
Remove the asterisk at the beginning of the statement, and replace
CNMTRMSG with the name of the DSIMSG member containing the translated
messages. For information about changing CNMSTYLE statements, see IBM
Tivoli NetView for z/OS Installation: Getting Started.
transMember = CNMTRMSG
This automatically loads the message translations the next time you start the
NetView program.
Messages issued during normal operation are translated as specified in the loaded
translation member.
|
Formatting of Globalization Feature Message Skeletons
You can write your own message translations for any message output by DSIPSS,
including all messages that can be displayed on the command facility screen. Some
messages that are displayed on full-screen panels cannot be translated. The
following rules are used to define single-byte character set (SBCS) and double-byte
character set (DBCS) message translations in a member of DSIMSG:
v Each message translation is defined only once. If you define it more than once,
the first copy is used for translation.
v The message translations are saved in 72-byte records.
v To code a comment, code an asterisk (*) at column 1 of a record.
v Each message translation contains a message identifier and a message text.
v The message identifier (msgid) is the first token delimited by a blank in the
translation. The msgid is divided into msgid1 and optionally msgid2. For single
line messages, or for lines of a multiline message which can be uniquely
identified by their first token, only msgid1 (for example, DSI633I) is needed.
Other multiline message lines can be specified as msgid1.msgid2 or msgid1.*
where msgid1 refers to the first token of the first line of the message, msgid2
refers to the first token of the target line, and the asterisk (*) refers to all lines of
the message identified by msgid1. Examples can be found in sample
CNMMSENU. Each identifier (msgid1 or msgid2) can contain a maximum of 12
characters. The msgid must start in column 1 of a record.
v The message text follows the message identifier. The format of the text is shown
here:
W1 &6 W2 W3 &4 and so on
Where:
|
|
Wx
Is globalization feature text.
&n
Is the message insert substituted from the corresponding token of the
English message, which can be qualified, as described below.
&n represents the nth token of the English message as described in
“Counting English Message Inserts for Globalization Feature Message
Skeletons” on page 229. If the specified insert number does not have a
corresponding token in the English message, the value is null. Valid
insert numbers are 1–128.
Chapter 14. Installing the Globalization Feature
227
v You can specify a single token or a token range. Specify a token range by
putting a dash (-) after the first token number followed by the second token
number. This indicates that the specified range is to be placed into the translated
text, including all blanks which precede each token in the range. Specifying a
range with only one token (for example &5-5) places that token into the
translated text with all its leading blanks. Omitting the range specification, (for
example &5) causes leading blanks to be dropped. The special token E means ″to
the end″. For example, &6-E specifies the sixth token (with leading blanks) to the
end of the message.
v You can use an optional length field with a message insert number through the
notation * in the following way:
&n*m
Where:
n
Is the insert number (or range).
Is the length of the insert value to be displayed. The valid length ranges
from 1–99. If the actual token is longer than m, the token is truncated. If
it is shorter, the token is padded with blanks.
You can use this notation for column alignment.
m
v Dates and times in a message token or token range can be translated into the
format which is customized by the DEFAULTS or OVERRIDE command. To do
this, specify the input date or time format enclosed in apostrophes after the
length above, or if the length is not included, after the token number and range.
For information about these formats, refer to the online help for the DEFAULTS
and OVERRIDE commands. The NetView program scans the token or tokens in
the message for a set of characters which matches this format. If a match is
found, the matching text is replaced by the customized format, using the same
number of characters that were in the original message. If more characters are
required or if no match is found, the token or tokens are inserted unchanged.
Examples can be found in sample CNMMSENU.
v The delimiter following the message insert must be either a blank or a period (.).
A period concatenates the value of the insert and the following text. For
example, if you specify &3 and the third token of the message is ABC, then
&3.DEF defined in a translation is represented as ABCDEF. If you specify &3 DEF
it is represented as ABC DEF.
v If a message translation is longer than one line, the continuation lines must start
in column 2. The data in these lines, excluding the blanks following the last
nonblank character in the preceding line, are concatenated. If the text is a DBCS
and concatenation results in a shift-in character followed by a shift-out character,
the redundant shift-in/shift-out is removed.
v Translated regular/HELD/REPLY messages cannot exceed 256 bytes, even with
the English tokens inserted.
v Translated immediate messages cannot exceed 10 characters less than the screen
width. For example, if you have a 24 x 80 character screen, immediate messages
cannot be longer than 70 characters. Be sure to code your immediate messages
based on the smallest terminal screen in your network.
v No individual line of a translated MLWTO message can exceed the width of a
screen. Be sure to code your MLWTO messages based on the smallest terminal
screen in your network. The characters exceeding the limits are truncated, and,
for a DBCS string, a shift-in character is added where appropriate.
228
Installation: Configuring Additional Components
|
|
|
Counting English Message Inserts for Globalization Feature
Message Skeletons
Command facility English messages are constructed from predefined message
words and dynamically assigned (by the message building modules) message
inserts. Only the predefined message text can be translated. If a globalization
feature message translation contains English message inserts, positions of these
inserts in the globalization feature message translation are shown by placing the
token numbers of these inserts from the English message at the places where they
are displayed. The token numbers of the message inserts of the English message
can be determined according to the following rules:
v The blank, comma, single quotation mark, and quoted string (a string enclosed
by quotation marks, as defined in the following items) delimiters are used to
separate the message into tokens. The message identifier is the first token. Each
word of the message text as delimited by blanks, commas, quotation marks, and
quoted strings is a separate token.
v A blank followed by a comma is interpreted as a token and uses a token
number.
v A character that is not a delimiter, followed by a comma and then a blank, is
interpreted as two spaces and does not use a token number.
v A quoted string begins with a single quotation mark that follows a delimiter
(blank, comma, or quotation mark). If a single quotation mark is found outside a
quoted string, it is considered to be a delimiter.
v A quoted string ends with a single quotation mark followed by one of these
characters:
– Blank ( )
– Colon (:)
– Comma (,)
– Exclamation point (!)
– Period (.)
– Question mark (?)
– Semicolon (;)
– Character X
Note: If a single quotation mark is found within a quoted string (and is not
followed by one of these characters), the quotation mark is interpreted as
part of the quoted string.
v All words in a quoted string are interpreted as a single token and use one token
number.
Use care in counting tokens to distinguish between quotation marks as ordinary
delimiters and as quoted string delimiters. For example, X'03', contains 3 tokens x, 03, and a null token; whereas, '03' contains only 1 token, 03, because it is a
quoted string.
|
The following examples show the token numbers of message inserts in command
facility English messages and how to put the token numbers into the translated
globalization feature message translations.
1. DSI422I SENSE CODE = X'code' REASON = error_message_text
Where the error_message_text can contain a maximum of four tokens.
&1 : DSI422I
&2 : SENSE
&3 : CODE
&4 : =
Chapter 14. Installing the Globalization Feature
229
&5 : X
&6 : code
&7 : REASON
&8 : =
&9 : 1st token of the error message
&10: 2nd token of the error message
&11: 3rd token of the error message
&12: 4th token of the error message
The message variable code has token number &6 and the string insert
error_message_text has the token numbers &9 and beyond. The message
translation can be:
DSI422I <ABC
DEF> = &9 &10 &11 &12 <GHIJ> = X'&6.'
where:
< Shows shift-out character
> Shows shift-in character
Suppose the English message issued is:
DSI422I SENSE CODE = X'00000014' REASON = INVALID STATION
The following translated message might be displayed on the operator screen:
DSI422I <ABC
DEF> = INVALID STATION
<GHIJ> = X'00000014'
2. DSI198I 'command' COMMAND NOT ALLOWED TO RUN UNDER tasktype TASK
This list shows the tokens:
&1 : DSI198I
&2 : command
&3 : COMMAND
&4 : NOT
&5 : ALLOWED
&6 : TO
&7 : RUN
&8 : UNDER
&9 : tasktype
&10: TASK
The message translation is:
DSI198I <ABC> &9 <DEF> '&2.' <GHI>
Suppose the English message that is issued is:
DSI198I 'HOLD SCREEN' COMMAND NOT ALLOWED TO RUN UNDER NNT TASK
The following translated message is displayed on the operator screen:
DSI198I <ABC> NNT <DEF> 'HOLD SCREEN' <GHI>
SNMP Limitations
Non-English SNMP data cannot be displayed correctly in the Web application
because SNMP data is not translated and is not enabled for multiple-byte
characters.
230
Installation: Configuring Additional Components
Appendix A. Running Multiple NetView Programs in the Same
LPAR
You can run multiple NetView programs in the same logical partition (LPAR), with
both controlling NetView management consoles.
One reason you might want to run two NetView releases on the same system is to
divide the work in your network. You might want to have one NetView program
perform systems automation functions, using a combination of NetView and
systems automation for z/OS programs. A second NetView program can be used
to perform network management and network automation functions, using a
combination of NetView functions, MultiSystem Manager, the SNA Topology
manager, and AON.
Another common reason to run two NetView releases is to keep a stable
production environment using your current NetView release while you are
installing and customizing the new NetView release. In this case, you can install
and use NetView V5R4 and keep your current NetView release installed and
running at the same time. You can install V5R4 on the same system as any other
NetView release as far back as NetView V2R4.
Configuring the Two NetView Programs
To configure multiple NetView programs to run on the same LPAR, you first need
to decide which is the primary NetView program. In this case, the primary NetView
program is the one that owns the CNMI interface and other tasks that cannot be
duplicated. The secondary NetView programs are the ones that must be configured
to coexist with the primary NetView program.
Follow these steps to configure a NetView V5 or later program as a secondary
NetView program:
Table 35. Steps to Configure a Secondary NetView Program
Step
Description
Define a separate
subsystem name in the
IEFSSNxx member of
SYS1.PARMLIB for the
secondary NetView
program and NetView
subsystem.
This subsystem name corresponds to the first four characters of
the secondary NetView program and NetView subsystem
procedure names.
© Copyright IBM Corp. 2001, 2009
231
Table 35. Steps to Configure a Secondary NetView Program (continued)
Step
Description
Create the SSI procedure
for the secondary
NetView program and
modify the SSI
definitions if you plan to
use the SSI interface
instead of extended
multiple console support
consoles to exchange
commands or messages
with MVS.
You can run with one SSI procedure. Only do this step if you
choose to have multiple SSI procedures (one for each NetView
program). The first four characters of this procedure name must
correspond to the subsystem name chosen for the secondary
NetView program.
v Create a separate SSI address space for the secondary
NetView program.
v Match the version and release of each SSI (for the primary
and the secondary NetView program) to the NetView version
and release.
v Specify a unique command designator for each SSI, in the
DSIG parameter of the SSI startup procedure. The DSIG
parameter must be unique within a sysplex.
v Specify NOPPI in the SSI startup procedure of the secondary
NetView program. MVS allows only one SSI to provide the
PPI function.
Allocate new VSAM
databases for the
secondary NetView
program and RODM.
Run NetView sample CNMSJ004, changing the data set names
to conform with your naming convention.
Allocate a new
DSIPARM data set for
the secondary NetView
program.
Copy the contents of the DSIPARM data set from the primary
NetView program to the DSIPARM data set for the secondary
NetView program.
Create and modify the
secondary NetView
startup procedure
(CNMSJ009).
v Change PROG=BNJLINTX to PROG=DSIMNT on the EXEC
statement.
v Change the VSAM and DSIPARM data set names to specify
the data sets allocated for the secondary NetView program.
v Assign a domain name for the secondary NetView program.
The first four characters of this procedure name must
correspond to the subsystem name chosen for the secondary
NetView program.
Create and modify the
secondary GMFHS
startup procedure
(CNMSJH10).
232
Installation: Configuring Additional Components
v Change the CNMPARM DD statement to specify the
DSIPARM data set you created for the secondary NetView
program. This data set contains the DUIGINIT initialization
member for GMFHS created when the secondary NetView
program is started.
v Assign a domain name for GMFHS.
Note: This is required only if the secondary NetView
program is V1R3 or later. If the secondary NetView program
is an earlier release level, you do not need to assign a domain
name for GMFHS.
Table 35. Steps to Configure a Secondary NetView Program (continued)
Step
Description
Create and modify the
secondary RODM
startup procedure
(EKGXRODM).
v Change the NAME parameter to identify the secondary
RODM.
v Change the EKGLOGP, EKGLOGS, EKGMAST, EKGTRAN,
and EKGDnnn DD statements to specify the new VSAM data
sets allocated for the secondary NetView program.
v Change the EKGCUST DD statement to specify the data set
that contains the customization and initialization member for
the secondary RODM.
Note: If you are using an SAF product, such as RACF, define
and authorize the user IDs used to connect to the secondary
RODM. For example, you can authorize the secondary NetView
program, and the DSIQTSK running in the secondary NetView
program, to be able to connect to RODM. For more information,
refer to IBM Tivoli NetView for z/OS Security Reference.
Create a secondary
RODM load job
(CNMSJH12).
v Specify the secondary RODMNAME.
Update DSIPARM
member DUIGINIT
(GMFHS initialization)
to configure the
secondary GMFHS.
If you are using system symbolics, some or all of these
modifications might not be necessary.
v Change RODMNAME to match the secondary RODM.
v Change DOMAIN to specify the secondary NetView domain,
or enter the secondary domain name as a GMFHS startup
parameter.
v If you are using an SAF product such as RACF, add the access
userid (RODMID statement) used to connect to the secondary
RODM.
v Comment out any SNA Topology Manager data model
samples (FLBTRDMx) so that they are not loaded into the
RODM data cache.
If necessary, update your To forward non-SNA alerts to a GMFHS other than the one
automation table for the associated with the secondary NetView program, modify the
GMFHSDOM value in the following statement:
secondary GMFHS.
IF (MSUSEG(0000)¬= '' | MSUSEG(0002) ¬= '') & HIER ¬= ''
THEN EXEC (CMD('DUIFECMV GMFHSDOM=xxxxx')
ROUTE(ONE DUIFEAUT)) CONTINUE(Y);
where xxxxx is the primary NetView domain name.
Appendix A. Running Multiple NetView Programs in the Same LPAR
233
Table 35. Steps to Configure a Secondary NetView Program (continued)
Step
|
|
|
|
|
|
|
|
|
|
Description
Configure the secondary v Disable the AAUTCNMI, DSIROVS, and DSIKREM tasks by
NetView program using
changing the CNMI statement in the following way:
the CNMSTUSR or
CNMI = NO
CxxSTGEN member. For v Change the PPI receiver name (DEFAULTS.PPIPREFX=
information about
&NV2I.) for the CNMCALRT task to any value other than the
changing CNMSTYLE
one that is used for the primary NetView program.
statements, see IBM
v Set the alias for the secondary GMFHS job name and
Tivoli NetView for
procedure name that are used with CNME2101 by modifying
z/OS Installation: Getting
the following statements:
Started.
COMMON.DUIFHNAM = GMFHS
COMMON.DUIFHPRC = CNMGMFHS
v Set the alias for the secondary RODM job name and
procedure name that are used with CNME1098 by modifying
the following statements:
v
v
v
v
COMMON.EKGHNAM = RODM
COMMON.EKGHPRC = EKGXRODM
Change the domain name (DOMAIN = C&NV2I.01) to a
unique value if it was not changed in the startup procedure.
If you are starting the NetView program by specifying
SUB=MSTR, the JES joblog is allocated by default when the
NetView task DSIRQJOB requests a job ID for the NetView
job. If the JES joblog is not wanted, change the joblog
constant.
Disable the MVS command management function by
changing the TOWER statement.
Disable the SNA Topology Manager by changing the Graphics
subtower statement in the following way:
TOWER.Graphics = *SNATM
v For the Tivoli NetView for z/OS Enterprise Management
Agent, enable the TEMA tower on only one NetView program
for each LPAR.
Note: If you decide to divide the TEMA functions between
NetView programs, the TEMA.SESSACT subtower is
supported on only one NetView program for each LPAR
(because of the DSIAMLUT session monitor task).
v To limit the discovery manager function because it is being
done by another NetView program on the LPAR, either turn
off the DISCOVERY tower completely or specify
DISCOVERY.NetViewOnly=YES in the CNMSTUSR or
CxxSTGEN member on the secondary NetView program.
v If the RMTCMD command or the CNMTAMEL task on two
NetView programs are to use TCP/IP and both are using the
same TCP/IP stack, specify the ports that are to be used for
these functions to avoid conflicts. The definition statements
are RMTINIT.PORT and TAMEL.PORT.
|
|
|
|
|
|
|
|
|
|
234
Update DSIPARM
member DSICNM to
configure the secondary
NetView program.
Insert an asterisk prior to the O MONIT statement and remove the
asterisk prior to the O SECSTAT statement.
Note: Only one status monitor can receive status updates from
VTAM. Other status monitors are secondary status monitors and
show all resources in NEVACT state.
Update DSIPARM
member DSIQTSKI to
configure the secondary
NetView program.
v Change the CMDRCVR ID to something other than DSIQTSK
if you want the secondary NetView program to have its own
PPI command receiver task.
v For RODM access and control, specify a valid REP statement
with the RODM name and user ID for connection to RODM.
Installation: Configuring Additional Components
Table 35. Steps to Configure a Secondary NetView Program (continued)
Step
Description
Create a new VTAM
APPL definition for the
secondary NetView
program.
If necessary, change the PPT APPL statement from PPO to SPO.
Only one NetView program can have the primary program
operator (PPO) interface. Unsolicited VTAM messages are only
sent to this NetView program.
NetView Task Restrictions
The VTAM and MVS products put some restrictions on how multiple NetView
programs can run on the same system. Some NetView tasks are assigned unique
names that cannot be changed because VTAM can only recognize one instance of
that task, with the specific assigned name. The following tasks cannot be
duplicated when running multiple NetView programs:
Table 36. Tasks that Cannot be Duplicated When Running Two NetView Programs
Task
Description
AAUTCNMI
Only one NetView program can own the communication
network management interface (CNMI). The CNMI is a VTAM
interface that NetView and other network management products
use to receive and send alerts and other information. Because
you cannot rename the AAUTCNMI task, only one NetView
program can activate the task. Do not have other NetView
programs activate AAUTCNMI. Other NetView programs can
access the data of the CNMI owner through a cross-domain
session.
DSIAMLUT
The DSIAMLUT task is used by the NetView session monitor to
receive session information from VTAM. VTAM can only
recognize one DSIAMLUT task, and the task cannot be renamed.
Thus, only one NetView program can activate DSIAMLUT. You
can still start the session monitor on other NetView programs,
but VTAM session information needs to be forwarded from the
NetView program on which DSIAMLUT is active.
DSICRTR
VTAM can recognize only one DSICRTR task with an active
APPL definition. However, you can define multiple DSICRTR
tasks on the same VTAM. For the first NetView program, in the
DSICRTR initialization member, code FUNCT=CNMI. For
additional NetView programs, code FUNCT=OTHER in the
DSICRTR initialization member. These NetView programs do
not receive any information over the CNMI interface.
DSIMCAT
Use the DSIMCAT task to automate MVS and subsystem
commands entered from any MVS console or console interface.
Only one NetView program on the same system can have the
DSIMCAT task active. Additional NetView programs cannot
start this task.
DSIKREM
The DSIKREM task communicates with remote 3172 and 3174
consoles. Because this task uses the CNMI, it is bound by the
limit of one per VTAM program. The second NetView program
cannot start this task.
DSIROV
The DSIROVS task provides Programmable Network Access
(PNA) support. Because this task uses the CNMI, it is bound by
its limit of one per VTAM program. Additional NetView
programs cannot start this task.
Appendix A. Running Multiple NetView Programs in the Same LPAR
235
Any application or NetView task name that has a domain-qualified name works
when running multiple NetView programs. Because each NetView program is
assigned to a different domain, the fully qualified network name of each
application or task (which includes the domain ID) is unique.
Using the Subsystem Router in a Sysplex Environment
When using extended multiple console support (EMCS) consoles, the subsystem
router obtains an EMCS console to receive unsolicited messages marked as able to
be automated in the MVS MPF table. This ensures compatibility when using EMCS
console support in the NetView program to replace SSI routing.
If you are running multiple NetView systems or if you are defining a sysplex
environment, use the ConsMask statement in the CNMSTUSR or CxxSTGEN
member to ensure that you have a unique subsystem router task name. For more
information about the ConsMask statement, see the IBM Tivoli NetView for
z/OS Administration Reference. For information about changing CNMSTYLE
statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
|
|
|
|
Assigning a Unique CNMCSSIR Task Name
A NetView-to-MVS interface task called CNMCSSIR can use EMCS consoles to
receive messages from MVS. The NetView program uses the name specified on the
SSIname statement in the CNMSTYLE member to determine the name of the
CNMCSSIR task. The NetView program uses the name of this task as the default
console name when extended MCS consoles are in use. You can specify ConsMask
in the CNMSTUSR or CxxSTGEN member. For information about changing
CNMSTYLE statements, see IBM Tivoli NetView for z/OS Installation: Getting Started.
|
|
|
Another way to avoid console ID conflicts for the CNMCSSIR task is to specify
MVSPARM.MSGIFAC=SSIEXT in the CNMSTUSR or CxxSTGEN member. You can
also set the MSGIFAC parameter in the NetView application and subsystem
startup procedures. This causes the CNMCSSIR task to use the subsystem interface
to receive messages from MVS while still allowing other NetView operator tasks to
use EMCS consoles.
|
Starting the NetView Program Before Starting JES
If you plan to start the NetView program and the SSI under the master subsystem
before you start JES, the following rules apply:
v Start the PROC with the START command using the parameter SUB=MSTR.
v When you start the NetView program with the SUB=MSTR parameter, use the
START TASK=DSIRQJOB command, for the SUBMIT or ALLOCATE
commands to complete successfully.
v Store the procedure in the data set SYS1.PROCLIB, not in a user PROCLIB
supported by JES.
v The procedures must contain only a single job step.
v You cannot reference SYSIN, SYSOUT, or VIO data sets. If you are using the
sample start procedures, comment out all references to the symbolic SOUTA=A
in CNMPROC (CNMSJ009).
v JES needs to remain coded as the primary subsystem. But in the IEFSSN
member for JES, code the NOSTART parameter so that MVS does not
automatically start JES at initialization.
v You cannot specify AMP=AMORG on a log data set.
236
Installation: Configuring Additional Components
v After DSIRQJOB receives a job ID from JES, if JES ends abnormally or ends
without notifying DSIRQJOB to release the job ID, DSIRQJOB and NetView
cannot be stopped before JES becomes active again. If JES is ended abnormally
or ended by a user from the command line, the user can use the NetView MVS
Command Management to circumvent this.
These are the steps to set up MVS Command Management to stop DSIRQJOB
when a command is enter to abnormally end JES (for example $PJES2,ABEND
or $PJES2,TERM).
1. Activate NetView MVS Command Management. Refer to the IBM Tivoli
NetView for z/OS Automation Guide for information about how to activate
NetView MVS Command Management.
2. If a Command Inclusion List is used, ensure that either the $PJES2,ABEND
command or the or $PJES2,TERM command is in the list. If a Command
Exclusion List is used, make certain that the command is not excluded. If a
Console Inclusion/Exclusion List is used, make certain that the console that
issues the command is included (or not excluded),
3. Give authority to DSIMCAOP to issue the NetView STOP Command.
4. Modify CNMENCXY so it issues STOP TASK=DSIRQJOB when the incoming
MVS command is either $$PJES2,ABEND or $PJES2,TERM.
Appendix A. Running Multiple NetView Programs in the Same LPAR
237
238
Installation: Configuring Additional Components
Appendix B. Data Collection and Display for the NetView User
Interfaces
Table 37 shows the requirements for data collection and display for the NetView
user interfaces.
Table 37. NetView Data Collection and Display
Data
Discovered
Collection Tower or Subtower
DVIPA
definition and
status
DVIPA
Distributed
DVIPA
DVIPA.DVTAD
DVIPA
connection
VIPA routes1
Event,
Sampled
(Sampling
Interval in
Seconds),
or
User
Real-time Interface
Display Tower or Subtower
Sampled
(3600) and
event
3270 session
DVIPA
Tivoli
Enterprise
Portal
TEMA.DVDEF
Sampled
(3600) and
event
3270 session
DVIPA.DVTAD
Tivoli
Enterprise
Portal
TEMA.DVTAD
DVIPA.DVCONN
Sampled
(3600)
3270 session
DVIPA.DVCONN
TEMA.DVCONN
DVIPA.DVROUT
Sampled
(3600) and
event
3270 session
DVIPA.DVROUT
Tivoli
Enterprise
Portal
TEMA.DVROUT
Sampled
(3600)
3270 session
DVIPA.DVROUT
Tivoli
Enterprise
Portal
TEMA.DVROUT
Distributed
DVIPA
connection
routing1
DVIPA.DVROUT
Sysplex
DISCOVERY
Event
NetView
management
console
GRAPHICS
Coupling
facility
DISCOVERY
Event
NetView
management
console
GRAPHICS
z/OS image
DISCOVERY
Event
NetView
management
console
GRAPHICS
NetView
application
DISCOVERY
Event and
sampled
(300)
3270 session
DISCOVERY
NetView
management
console
GRAPHICS
Tivoli
Enterprise
Portal
TEMA
© Copyright IBM Corp. 2001, 2009
239
Table 37. NetView Data Collection and Display (continued)
Data
Discovered
Collection Tower or Subtower
Event,
Sampled
(Sampling
Interval in
Seconds),
or
User
Real-time Interface
TCP/IP stack
DISCOVERY
Event
TCP/IP subplex DISCOVERY
IP interface
Telnet server
and port
DISCOVERY.INTERFACES
DISCOVERY.TELNET
Display Tower or Subtower
3270 session
DISCOVERY
NetView
management
console
GRAPHICS
Tivoli
Enterprise
Portal
TEMA.SYSPLEX
3270 session
DISCOVERY
NetView
management
console
GRAPHICS
Sampled
(3600)
3270 session
DISCOVERY.INTERFACES
NetView
management
console
GRAPHICS
Event and
sampled
(3600)
3270 session
DISCOVERY.TELNET
NetView
management
console
GRAPHICS
Tivoli
Enterprise
Portal
TEMA.TELNET
Sampled
(3600)
3270 session
DISCOVERY.INTERFACES.OSA
NetView
management
console
GRAPHICS
Event
Open Systems
Adapter (OSA)
interface
(including
VLAN)2
DISCOVERY.INTERFACES.OSA
OSA2
DISCOVERY.INTERFACES.OSA
Sampled
(3600)
NetView
management
console
GRAPHICS
OSA channel
and port2
DISCOVERY.INTERFACES.OSA
Sampled
(3600)
3270 session
DISCOVERY.INTERFACES.OSA
Tivoli
Enterprise
Portal
TEMA.OSA
HiperSockets
interface
(including
VLAN)1, 2
DISCOVERY.INTERFACES.
HIPERSOCKETS
Sampled
(3600)
3270 session
DISCOVERY.INTERFACES.
HIPERSOCKETS
NetView
management
console
GRAPHICS
HiperSockets
adapter1, 2
DISCOVERY.INTERFACES.
HIPERSOCKETS
NetView
management
console
GRAPHICS
240
Installation: Configuring Additional Components
Sampled
(3600)
Table 37. NetView Data Collection and Display (continued)
Collection Tower or Subtower
Event,
Sampled
(Sampling
Interval in
Seconds),
or
User
Real-time Interface
Display Tower or Subtower
Interface and
TCP/IP stack
HiperSockets
configuration1, 2
DISCOVERY.INTERFACES.
HIPERSOCKETS
Sampled
(3600)
3270 session
DISCOVERY.INTERFACES.
HIPERSOCKETS
Tivoli
Enterprise
Portal
TEMA.HIPERSOCKETS
NetView task
TEMA.HEALTH
Data
Discovered
|
Sampled
(30)
3270 session
Tivoli
Enterprise
Portal
TEMA.HEALTH
TCP/IP inactive TCPIPCOLLECT.TCPCONN
connection
TEMA.CONINACT
Sampled
(3600)
3270 session
TCPIPCOLLECT.TCPCONN
Tivoli
Enterprise
Portal
TCPIPCOLLECT.TCPCONN
TEMA.CONINACT
TCP/IP active
connection
Real-time
3270 session
TEMA.CONNACT
Sampled
(900)
Tivoli
Enterprise
Portal
TEMA.CONNACT
NLDM
Sampled
(900)
3270 session
NLDM
Tivoli
Enterprise
Portal
TEMA.SESSACT
Session data
Notes:
|
1. z/OS V1R11 Communications Server or later is required.
2. RODM must be running for the data to be displayed.
Appendix B. Data Collection and Display for the NetView User Interfaces
241
242
Installation: Configuring Additional Components
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the user’s responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not give you
any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785 U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM
Intellectual Property Department in your country or send inquiries, in writing, to:
Intellectual Property Licensing
Legal and Intellectual Property Law
IBM Japan, Ltd.
1623-14, Shimotsuruma, Yamato-shi
Kanagawa 242-8502 Japan
The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION ″AS IS″ WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Some states do not allow disclaimer of express or implied warranties in certain
transactions, therefore, this statement might not apply to you.
This information could include technical inaccuracies or typographical errors.
Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.
© Copyright IBM Corp. 2001, 2009
243
IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:
IBM Corporation
2Z4A/101
11400 Burnet Road
Austin, TX 78758 U.S.A.
Such information may be available, subject to appropriate terms and conditions,
including in some cases payment of a fee.
The licensed program described in this document and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement or any equivalent agreement
between us.
Information concerning non-IBM products was obtained from the suppliers of
those products, their published announcements or other publicly available sources.
IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which
illustrate programming techniques on various operating platforms. You may copy,
modify, and distribute these sample programs in any form without payment to
IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating
platform for which the sample programs are written. These examples have not
been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or
imply reliability, serviceability, or function of these programs. The sample
programs are provided ″AS IS″, without warranty of any kind. IBM shall not be
liable for any damages arising out of your use of the sample programs.
Each copy or any portion of these sample programs or any derivative work, must
include a copyright notice as follows:
© (your company name) (year). Portions of this code are derived from IBM Corp.
Sample Programs. © Copyright IBM Corp. _enter the year or years_. All rights
reserved.
Programming Interfaces
This publication primarily documents information that is NOT intended to be used
as Programming Interfaces of Tivoli NetView for z/OS. This publication also
documents intended Programming Interfaces that allow the customer to write
programs to obtain the services of Tivoli NetView for z/OS. This information is
identified where it occurs, either by an introductory statement to a chapter or
section or by the following marking:
244
Installation: Configuring Additional Components
Programming Interface information
End of Programming Interface information
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of
International Business Machines Corporation in the United States, other countries,
or both. If these and other IBM trademarked terms are marked on their first
occurrence in this information with a trademark symbol (® or ™), these symbols
indicate U.S. registered or common law trademarks owned by IBM at the time this
information was published. Such trademarks may also be registered or common
law trademarks in other countries. A current list of IBM trademarks is available on
the Web at ″Copyright and trademark information″ at http://www.ibm.com/legal/
copytrade.shtml .
Adobe is a registered trademark of Adobe Systems Incorporated in the United
States, and/or other countries.
Microsoft and Windows are trademarks of Microsoft Corporation in the United
States, other countries, or both.
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the
United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Linux is a registered trademark of Linus Torvalds in the United States, other
countries, or both.
Other company, product, and service names may be trademarks or service marks
of others.
Notices
245
246
Installation: Configuring Additional Components
Index
Special characters
&CNMTCPN 141
&SYSCLONE 236
Numerics
3270 Telnet session 135
3270-type sessions 187
3767-type sessions 187
4700 support facility 3
defining 35
security 35
solicited commands 13
starting 36
stopping 36
VSAM considerations 21
VSAM database automation 192
47xx finance communications systems
3
A
A (message alert settings) statement 23
A01APPLS (CNMS0013)
source LUs for TAF 187
STATOPT statement 27
A01SNA 28
A04A54C 27
AAUDCPEX 120
AAUKEEP1 41
AAUTCNMI task 43, 235
AAUTSKLP task 43
accessibility xvii
additional source LUs, defining 187
address of commands
entry 116
exit 116
used as a parameter 116
Advanced Peer-to-Peer Networking
AON/SNA monitoring 68, 75
session configuration 185
topology 2
AIP status 49
alarms for panel messages 23
alert
forwarding 182
alert adapter service 213
alert-to-trap service 216
alerts 175
automation 3
forwarding through LU 6.2 177
generic 34
intermediate node alert focal point 178
LU 6.2 177
LUC, forwarded 178
receiver support, generic automation 16
settings 23
tasks 177
TCP/IP, forwarding 179
AMODETAB (CNMS0001)
logmode table 188
© Copyright IBM Corp. 2001, 2009
AON
adjacent NetViews 48
automation log 49
automation log, switching 50
automation operators 46, 48
CNMPROC 47
CNMSTYLE statements 44
commands 71
control file policy definitions 48
cross-domain logons, automation 48
domain ID, changing 47
environment AIP status 49
environment exit 49
focal point services 49
gateway operators 46
IDS support 45
monitoring 49
NCP recovery 49
NetView for AIX, disabling support 56
NetView for UNIX service point 50
notification forwarding 49
notification operators 49
overview 3, 43
panels 70
printing 50
RACF 49
restricting access 51
REXX command lists 109
REXX environment blocks 52
setting up focal-point services 81
SNA feature 45
SNA X.25 support 45
SNBU environment 49
subarea support 68
tailoring 69
tasks 70
TCP/IP definitions 50
TCP/IP feature 45
testing 70
thresholds 49
timeout 49
timer automation 49
TSO command servers 57
UNIX command servers 56
VSAM databases 45
X.25 monitoring 50
AON/SNA
Advanced Peer-to-Peer Networking monitoring
automation log, displaying 73
control file policy definitions 48
NCP recovery 74
setup 67
SNA X.25 monitoring 77
SSI, defining 67
testing 72
thresholding 74
X.25 support 69
AON/SNA feature 45
AON/TCP
autotask 62
command servers 56
68, 75
247
AON/TCP (continued)
control file policy definitions 48
cross-domain communication 60
functions 54
IDS 65
monitoring 62
service points 60
set up 54
setting up 52
SNMP support 59
TSO command servers 57
UNIX command server 202
UNIX command servers 56
APPCCMD retries 14
AREC filter 177
assign operator to group 98
ATCCONxx (CNMS0003) 26
ATCSTRxx (CNMSD021) 29
AUTOFLIP operand on the LOGINIT statement
automatic reactivation of nodes 22
automation
AON 43
automation table 191
CICS 220
common base event manager 6
Common Base Events 6
Common Event Infrastructure 6
correlation 6
correlation engine 6
DB2 221
event correlation 6
IMS 220
message monitoring 220
processor operations 221
SMF record type 30 197
System Automation 219
TWS 221
automation log 73
automation notifications 81
automation operators, defining 46
automation table 4
command missing 15
Event/Automation Service 213, 214
forwarding alerts 192
forwarding messages 192
frame relay 191
MVS subsystem messages 220
NCP information 191
overview 191
VSAM database automation 192
AUTONVSP autotask 128
AUTOOPS policy 60
AUTOOPS statement 151
AUTOSMF3 autotask 197
autotasks
TCP/IP 62, 151
BNJPNL2 statement 35
books
see publications xiii
both (B) command type 115
BPXPRMxx member, updating
browse facility 3
BSAM, sequential log 170
buffer pools, defining 17
buffers, allocating 18
C
167
B
B (both) command type 115
BGNSESS command and TAF
BNH874I message 197
BNJ36DST 21, 35
BNJDSE36 task 36
BNJDSERV task 35, 36
BNJMNPDA task 35
BNJPNL1 34, 35
248
203
187
Installation: Configuring Additional Components
C language
using with NetView 113
CDLOG 61
channel, defining to status monitor 29
CICS (Customer Information Control System)
CICS automation 220
CMDDEF statement 114
CMDSYN statement 116
CNM router 184
CNMCMD
adding CMDDEF statements 114
CNMCONxx 26, 30
CNMCSSIR
assigning unique name 236
CNME1049 98
CNMEERSC discovery commands 160
CNMEUNIX 208, 210
CNMI interface 231
CNMIPCS exit routine 173
CNMKEYS 99
CNMMSJPN 225
CNMPOLCY 52, 59, 147, 202
CNMPROC
AON 47
SOAP server 129
CNMPRT 167, 225
CNMS0013 (A01APPLS)
defining source LUs 187
CNMS0038 (CTCA0102) 29
CNMS0055 10
CNMS0065 27
CNMS0073 28
CNMS0081 (CTNA0104) 29
CNMS6214 167
CNMSCM 64, 153
CNMSCNFT
formatting messages 10
CNMSDVCG 139
CNMSDVTP 139
CNMSI101 120
CNMSIHSA 192, 213
CNMSJ004 45
CNMSJ009 121
CNMSJM01 17, 19
CNMSJM04 167
CNMSJM10 38
CNMSJSQL 121
CNMSJTSO 122
CNMSJUNX 56, 149, 209
CNMSJZC 218
CNMSMF3A command list 198
CNMSMF3E exit 197
CNMSMF3E sample 197, 198
CNMSSMON 139
CNMSSMON sample 141
188
CNMSSTSO 122
CNMSSUNX 209
CNMSTSOS command 122
CNMSTYLE 9, 21
alert information 178
ALRTINFP statement 178
AON, enabling 44
ASSIGN 98
C environment 114
commands, suppressing 98
common global variables 15
COMMON.IPPORTMON statements 146
COMMON.SSINAME 236
defaults 100
hardware monitor 33, 35
HLL environment 113
inStore 21
Japanese support 225
JesJobLog 166
memStore 21
MS transport task statement 119
NetView SNMP command 58, 150
network log facility 166
OpDsPrefix 98
PL/I environment 113
policy services 45
sequential logging 171
SQLOGTSK 171
status monitor 31
System Automation 219
TCP/IP trace 66, 155
TESTPORT statements 146
WLM 196
CNMSUNXS command 209
CNMTRMSG 225
CNMTRUSR 225, 226
code page 226
coding sample 41
coding, user command processor 116
color
changing hardware monitor panel 35
codes for messages 23
defining screens using CNMSCNFT 10
command
echoes, suppressing 117
issuing MVS 118
module, load 115
processors
adding 114
suppression 98
synonym 116
type 115
command facility 1
constants module 10
panel format 10
command help 7
command list
REXX 109
running from status monitor 21
synonym 116
command revision table 5, 194
command servers
defining 149
commands, IP 52
common base event manager 6
Common Base Events 6
Common Event Infrastructure 6, 217
Common Event Infrastructure (continued)
environment variables 205
common global variables
access time 15
OpDsPrefix 98
COMMON.IPPORTMON.INTVL statement 146
COMMON.IPPORTMON.IPADD statement 146
COMMON.IPPORTMON.PORTNUM statement 146
communication
cross-domain 151
community names 64, 153
CONFIG parameter 30
configuration file
snmpd.conf 140
sphere of control 180
confirmed alert adapter service 214
confirmed message adapter service 214
connection, IP 52, 147
connections, TCP/IP 64, 153
constants module, assembling and link-editing NetView
control file
Advanced Peer-to-Peer Networking monitoring 68
policy definitions 48
conventions
typeface xviii
correlation engine 6
starting 218
corrstart.sh 218
cross-domain communication 151
CRT 194
CSCF
application idle time 14
VSAM considerations 20
CTCA0102 (CNMS0038) 29
CTNA0104 (CNMS0081) 29
CTRACE 66, 155
customization
TSO command server 122
UNIX command server 208
10
D
D (data services) command type 115
DASD (Direct Access Storage Device)
parameter on KCLASS statements 41
data collection
DVIPA 139
data discovery 159
data log 165
data REXX 109
data services command type 115
database
defining
4700 support facility 35
network log 166
session monitor 36
save/restore
defining 120
DB2 121
DB2 automation 221
DBCS (double-byte character set) 227
DEFAULTS STRTSERV command 209
DEFENTPT statement 176
DEFFOCPT statement
alert forwarding 183
operations management 176
Index
249
defining
4700 support facility 35
alert network operations support 16
buffer pools 17
channel to status monitor 29
frame relay support 191
hardware monitor 33
high performance transport 120
MS transport 119
network
to status monitor 26
nodes 26
PA and PF keys 99
passwords
4700 support facility database 35
passwords for
AON 46
hardware monitor database 34
session monitor database 37
passwords for save/restore function 121
session monitor 36
SNA resources to status monitor 24
VSAM database automation 192
VSAM performance options 20
VTAM resources to status monitor 24
delay intervals, DVIPA 141
DFR value 20
directory names, notation xix
discovery commands, CNMEERSC 160
discovery library adapter (DLA) 124
distributed host 183
DLOGMOD operand 188
domain ID
AON 47
double-byte character set (DBCS) 227
DSI6DST task 35
DSI6INIT 119, 177
DSI6SCF 180
DSIAMLUT task 43, 235
DSICNM 21
DSICORSV task 218
DSICRTR task
hardware monitor 35
multiple tasks 235
session monitor 43
DSICRTTD 182
DSICTMOD 10, 184
DSIDB2DF 122
DSIDB2MT task 121
DSIEBCDC 225
DSIHINIT 120
DSIINP statement to print log 167
DSIKANJI 225
DSIKINIT 20
DSIKREM task 235
DSILOGBK 166
DSIMCAT task 235
DSIMSG 226
DSINDEF network definition
description 25
DSIOPF
operator definition 97
DSIPLXnn groups 161
DSIPRFGR 16
DSIRHOST 136
DSIROVS task 235
DSIRQJOB task 166
250
Installation: Configuring Additional Components
DSIRTTR task 179
DSIRTTTD
definition statement keywords 179
DSIRVCEX load module 193
DSISMF3F command 197
DSISVRTD 20
DSITBL01
forwarding alerts 192
forwarding messages 192
frame relay support 191
VSAM database automation 192
DSIWBTSK task 104
DSIXCFMT task 160
DSIZVLSR 20
DSRBO 182
DSRBO operand on DSTINIT statement
allocating buffers 18
DSTINIT statement
hardware monitor password 34
save/restore function 121
session monitor password 37
DUIFSTRC 226
DVIPA
data collection 139
delay intervals 141
distributed, statistics 142
events 139, 141
sysplex monitoring messages 141
TCPIP profile 141
traps 139, 140
DVIPA.STATS. TCPNAME.z 142
DVIPA.STATS.DVIPA 142
DVIPA.STATS.PORT 142
DVIPA.STATS.Pri.MAXR 142
DVIPA.STATS.Sec.MAXR 142
DVIPSTAT autotask 142
E
E/AS (Event/Automation Service) 6
ECHO operand on CMDDEF statements 117
echoes, suppressing command 117
editing utility for web.xml file 104
education
see Tivoli technical training xvii
embedded version of WebSphere Application Server 104
ENT.INT.name 159
ENT.SYSTEMS.name 159
Enterprise Management Agent, Tivoli NetView for z/OS 5
enterprise RODM 159
entry point application 175
environment variables 205
environment variables, notation xix
ESCON Manager 221
ESREC filter 177
event correction 6
event correlation
overview 217
event data 2
event receiver service 215
Event/Automation Service
alert adapter service 211, 213
alert-to-trap service 211, 216
alerts 211
confirmed alert adapter service 211, 214
confirmed message adapter service 211, 214
defining 211
globalization 225
globalization feature, installing 225
Graphic Monitor Facility host subsystem
GSKit 129
Event/Automation Service (continued)
event receiver service 211, 215
hardware monitor considerations 213, 214
host components 211
message adapter service 211, 213
messages 211
MultiSystem Manager 215
overview 210
started, using a command shell 212
started, using IHSAEVNT 211
starting 216
TCP/IP configuration data 202
trap-to-alert service 211, 215
Event/Automation Service (E/AS) 6
events
common base event manager 6
Common Base Events 6
Common Event Infrastructure 6
correlation 6
correlation engine 6
DVIPA 139, 141
exit address, system or VTAM 116
EZLCFG01 48, 50
EZLEISP1 47
EZLEISP2 47
EZLINSMP 66, 155
EZLOPF 46
EZLSJ006 46
EZLSUP01 51
EZLSUS01 51
EZLTLOG 49
H
hardcopy log, defining printer for 99
HARDCOPY statement 99
hardware information 2
hardware monitor 2
ALERT-NETOP application 177
alerts 179
changing color of panels 35
defining 33
filters 177
generic alert code points 34
LUC alert forwarding 184
remote data retrieval 13
RESTYLE command 33
solicited commands 13
starting 35
stopping 35
Tivoli management region resources 219
VSAM considerations 20
VSAM database automation 192
HEAP size, default 13
help desk
AON 3
NetView 7
help facility 7
HFS data set, mounting 203
high performance transport, defining 120
high-level languages
constants 13
using with NetView 113
highlighting messages 23
HOSTPU parameter 30
HOSTSA parameter 30
F
filtering, sense code
defining 38
FKVOPF 46
FKVTABLE 68
FKXCFG01 48
FKXERINI 62
FKXOPF 46
FKXTABLE 52, 56, 147
focal point
NetView 181
sphere of control 180
target systems, monitor 219
user-defined 179
focal point application 175
Focal-point services 81
forwarding
alerts 182
operations management data 175
frame relay switching equipment support 191
full-screen sessions 186
FUNCT operand on DSTINIT statement 9
I
G
gateway operators, defining 46
Gateway Password Maintenance 94
gateways 83
generic alert code points 34
generic automation receiver support 16
GETPW 94
global variable save/restore function, defining
GLOBALCONFIG statement 141
4
120
I/O Operations 221
IBM Tivoli Change and Configuration Management Database
(IBM Tivoli CCMDB)
discovery library adapter (DLA) 124
ibmMvsDVIPARemoved 140
ibmMvsDVIPAStatusChange 140
ibmMvsDVIPATargetAdded 140
ibmMvsDVIPATargetRemoved 140
ibmMvsDVIPATargetServerEnded 140
ibmMvsDVIPATargetServerStarted 140
IDS 45, 53, 65, 147, 154
IEFACTRT SMF installation exit 197
IEFSSNxx 231
IHSAACDS 212
IHSAACFG 212
IHSAATCF 212
IHSABCDS 212
IHSABCFG 212, 214
IHSAC000 216
IHSAECDS 212
IHSAECFG 212
IHSAEVNT 210, 216, 218
IHSAEVNT sample 211
IHSAINIT 212
Index
251
IHSALCDS 212
IHSAMCFG 212
IHSAMFMT 212
IHSAMSG1 212
IHSANCFG 214
IHSANFMT 212
IHSATALL 212
IHSATCDS 212
IHSATCFG 212
IHSATMSM 212
IHSATUSR 212
ihsread1 211
immediate (I) command type 115
IMS (Information Management System), accessing
IMS automation 220
inactivity interval, session 184
indicator settings, message 23
INFORM policy 66, 155
Init.DVIPASTATS 142
interactive problem control system (IPCS) 173
intermediate node alert focal point 178
Intrusion Detection Services 45, 53, 65, 147, 154
IP
autotask 151
IP commands 52
IP connection 52, 147
monitoring policy 65, 154
IP connection monitoring 53, 147
IP interface 63, 152
IP management
required statements 134
UNIX command servers 149
IP resource manager 53, 147
IP resources
monitoring 147, 152
IP server management 52
IP support 52, 147
IP trace 54, 147
IPCS 173
IPINFC 63, 152
IPNAMESERV 63, 152
IPPORT 63, 65, 152, 154
IPROUTER 62, 152
IPTELNET 63, 152
IPTN3270 63, 152
IPv6Env statement 134
IRXANCHR table 110
IRXANCHR table in TSO/E 111
IRXTSMPE 110
issuing MVS commands from NetView 118
L
189
J
JAPANMSG 225
JES joblog 166
JES, starting NetView
236
K
Kanji 225
KCLASS statements 41
coding in the NetView Program
keys, defining 99
252
41
Installation: Configuring Additional Components
limitations, non-English SNMP data 230
Link Pack Area (LPA)
building pageable 113
LIST parameter 30
listeners, hung 146
LISTWLM 196
loading a command module at run time 115
local management interface (LMI) 191
log
hardcopy, defining 99
network, defining 166
passwords
network 166
sequential, defining 170
log browse
overview 3
LOGINIT statement 167
logmode table
changing 187
point to using MODETAB parameter 188
logon ID 97
LOGPROF1 98
LookAt message retrieval tool xvi
LSR (Local Shared Resources) 17
LSR value 20
LU 6.2
alerts, forwarding 178
transport support 14
LU topology 2
LU1 sessions 187
LU2 sessions 187
LUC alert forwarding 182
LUC session 184
LUs, additional source 187
M
major node, definition 25
manuals
see publications xiii, xvi
MAPSESS statements
coding in the NetView Program 41
master NetView program 157
switching 160
MAXPROCSYS statement 134
MAXPROCUSER statement 134
member 26
member browse
overview 3
MEMSTORE 21
message
alert settings 23
automation 3
forwarding 192
help 7
indicator settings 23
skeletons, globalization feature 227
translation 225
message adapter service 213
message retrieval tool, LookAt xvi
message revision table 5, 193
message translation, defining 226
messages
action, MVS 192
revising 193
MIB data 64, 153
minor node
defining 25
MOD operand on CMDDEF statement 114
MODETAB parameter 188
MPF exit for MVS command revision 193
MPFLSTxx, updating 193
MS transport 175
MS transport, defining 119
MultiSystem Manager 3
Event/Automation Service 215
REXX command lists 109
Tivoli management region resources 219
MVS
workload management 194
MVS command revision 193
MVS messages, action 192
MVS START command
CNMSTSOS 122
MVSCMDS operator ID 193
N
name of resource 26
NCP recovery 49, 74
NETCONV connections 161
NETID operand on PARTNER statement 120
NetView
command environment 109
components 1, 9
configuring multiple releases 231
constants module, assembling and link-edit 10
constants used at a status focal point 14
data set members, browse 3
DB2 121
defaults, initial 100
focal point 175
high performance transport 120
JES, starting 236
local TCP/IP stacks 59, 150
log, browse 3
MS transport 119
MVS command revision 193
operator definition 97
operator environment 97
optional services 119
PDS members, storage considerations 21
performance 16
SQL 121
storage management 14
subtasks 196
task restrictions 235
translation 225
TSO command server 122
UNIX commands 208
VTAM APPL statements 235
Web server interface task 104
NetView connection 85
NetView for AIX 56
NetView for UNIX service point 50
NetView for z/OS Enterprise Management Agent
OMEGAMON workspaces 222
NetView program
basic 157
master 157
master-capable 157
non-member of an XCF group 157
NetView SNMP support 150
NetView SNMP Support 58
NetView UNIX command server JCL 207
network log 166
defining 166
passwords 166
printing 167
VSAM considerations 20
network resources, failing information 2
NLOG command 73
NOACTY operand on STATOPT statement 27
nonpersistent sessions timeout 11
nonpersistent sessions, establishing 184
NOSAW operand on MAPSESS statement 43
notation
environment variables xix
path names xix
typeface xix
Notation Forwarding, Implementing 91
NOTIFY policy 65, 155
NTFYOP policy 65, 155
NVSP statement 128
nvsrvc utility
Web server 104
O
O SECSTAT 22
OMEGAMON XE products
NetView for z/OS Enterprise Management Agent 222
NetView interoperation with 222
NetView Web application 222
OMIT operand on STATOPT statement 27
online publications
accessing xvi
OpDsPrefix 98
operations management support, forwarding data 175
operator
assign to group 98
command suppression 98
control sessions 186
data sets 98
operator ID
defining 97
operator-control sessions
defining to applications 187
SRCLU statements with 188
with TAF 186
ordering publications xvii
OSATRACE 66, 155
OSNMPD 140
overview 1, 2, 3, 4, 7
P
P command type 115
PA keys, defining 99
pacing interval 159
password
defining database
4700 support facility 35
hardware monitor 33
network log 166
save/restore 121
SRCLU 187
passwords 84
Index
253
path names, notation xix
performance 113
performance data, OMEGAMON
configuring for display in the Web application 107
PF keys, defining 99
PKTTRACE 66, 155
PL/I language
using with NetView 113
policy services 45
ports
critical, monitoring 146
PPI
receiver 208
PPI (program-to-program interface) 5
preferences files
Web application 107
preinstallation tasks
updating the IRXANCHR table 111
preprocessor, running status monitor 29
PRI operand on MAPSESS statement 42
printer
hardcopy log, defining 99
LU name 99
printing logs
network 167
problem determination 173
processor operations component 221
program region size, determining 31
program-to-program interface (PPI) 5
PROGxx
Web Services server 130
public message queue, default threshold values for 13
publications xiii
accessing online xvi
ordering xvii
Q
query PSID request
11
R
R (regular) command type 115
RACF
defining operators 46
RD command type 115
reactivation of failing nodes, specifying automatic 22
readme files
ihsread1 211
znetview_webapp_readme_en.htm 104
recommended actions 7
region size
determining program 31
remote commands 97
resident in active storage, command module 115
resource
routing definitions statement 100
resource manager, IP 53, 147
Resource Object Data Manager (RODM)
overview 4
RESUME operand on LOGINIT statement 167
revising messages 193
REXX
environment 110
environment blocks 52
translation 225
254
Installation: Configuring Additional Components
REXX (continued)
using with NetView 109
REXX environments 111
REXXENV 110
REXXSLMT 110
REXXSTOR 110
RMTCMD command 97
RODM
enterprise 159
overview 4
ROUTE filter 177
router 62, 152
router routine 81
RRD statement 100
RSH server 136
RU sizes
logmode table 189
running the status monitor preprocessor
29
S
samples
CNMSIHSA 213
IHSAEVNT 211
IHSANCFG 214
proxy clients 131
save/restore database
automation 192
defining 120
VSAM considerations 20
SAW data 41, 42
SAW operand
on KCLASS statement 41
SBCS (single-byte character set) 227
SEC operand on MAPSESS statement 42
SECOPTS statements 97
security
4700 support facility database 35
AON database 46
hardware monitor database 34
network log database 166
operator definition 97
save/restore database 121
session monitor database 37
Web Services server 130
sense code
filtering, defining 38
information 7
sequential access method logging support, defining
sequential log 170
server 63, 152
server, command, TSO
customizing 122
server, command, UNIX
customizing 208
server, Telnet 63, 152
server, TN3270 63, 152
service point
command completion 12
servlet mapping (URL pattern)
for Web application 105
session
3270-type 187
3767-type 187
data, collecting 41
establishing nonpersistent 184
full-screen 186
170
session (continued)
LU1 187
LU2 187
operator-control 186
partners 42
session monitor 2
Advanced Peer-to-Peer Networking sessions 185
connectivity test timeout 10
database
maintenance 165
database password 37
defining 36
gateway boundary function trace request timeout 11
gateway trace initialization timeout 10
KCLASS statements 41
line map request timeout 11
MAPSESS statements 41
NCP boundary function trace timeout 11
query PSID request timeout 11
route test timeout 11
RTM collection 12
RTM initialization 12
SAW data 41, 42
sense code filtering 38
starting 43
stopping 43
tasks 43
trace initialization timeout 10
trace NCP command 12
VR status request 12
VSAM considerations 20
VSAM database automation 192
settings files
Web application 107
size, determining program region 31
SMF record type 30 197
SMF30 statement 197
SNA sessions 2
SNA subarea network resources 4
SNA terminal
3270 187
3767 187
SNA topology manager 2
SNA X.25 monitoring 77
SNBU automation 49
SNMP agent 140
SNMP functions 53, 147
SNMP limitations, non-English data 230
SNMP request
policy definitions 59
SNMP support, NetView 58, 150
snmpd.conf configuration file 140
SOAP server
CNMPROC 129
verifying installation 131
SOASERV command 128
SOC-MGR 180
socket 63, 152
software applications, information 2
source LUs, defining additional 187
sphere of control 180
SQL 121
SRCLU, defining 187
SSIname 236
Stack 62, 152
stack management 52
stack monitoring 147
stack size 13
START parameter 30
START TSOSERV command 122
START UNIXSERV command 209
statements
AUTOOPS 151
IPv6Env 134
MAXPROCSYS 134
MAXPROCUSER 134
policy 135
required for IP management 134
TCPname 134
XCF.RANK 157
statistical data 2
statistics, distributed DVIPA 142
STATMON command 31
STATOPT statement 27
status forwarding 29
status monitor 4
automatic reactivation of nodes 22
channel definition 29
command lists 21
defining SNA resources 24
message indicator settings 23
multiple NetView programs 234
network definition 26
nodes, defining 25
overview 21
preprocessor, running 29
program region size 31
recovery of failing devices 23
resource names 26
resource, initial status 24
starting 31
status forwarding 29
status information 23
stopping 33
testing 31
unsolicited messages 22
STEPLIB 113
storage
discarding SAW data to save 43
loading command modules to save 115
storage management 14
subarea resource automation support 68
subarea topology 2
subsystem interface 5
subsystem name 231
subsystem router 236
suppressing
command echoes 117
commands 98
suppression character 98
synonym
command 116
parameter 118
sysplex environment 236
sysplex monitoring messages 141
System Automation
CICS automation 220
DB2 automation 221
IMS automation 220
overview 219
processor operations 221
system operations 220
TWS automation 221
System Automation address space 194
Index
255
system operations component
system symbolic
&CNMTCPN 141
&SYSCLONE 236
220
T
TAF 81
alerts 178
CICS, accessing 188
CLSDST(PASS) applications, accessing 189
default LU names 189
defining 186
IMS, accessing 189
LUC alert forwarding 184
TSO, accessing 189
task global variables
access time 15
tasks
AAUTCNMI 43
AAUTSKLP 43
AON 70
AONBASE 70
AONMSG1 70
AONMSG2 70
AUTALRT 70
AUTTRAP 70
BNJDSE36 36
BNJDSERV 35, 36, 177
BNJMNPDA 35
DSI6DST 35, 177
DSIAMLUT 43
DSICORSV 218
DSICRTR 35, 43
DSIDB2MT 121
DSIIPLOG 135
DSILOG 166
DSIRSH 135
DSIRTTR 179
DSIRXEXC 135
DSIWBTSK 104
EZLTCFG 70
EZLTDDF 70
EZLTLOG 70
EZLTSTS 70
restrictions, multiple NetView programs 235
REXX command lists 109
SQLOGTSK 171
USRSQLOG 173
tasks in A01APPLS, including user-written 9
TCP/IP
alerts 179
AON definitions 50
autotask 62, 151
services 135
UNIX sockets application 201
TCP/IP connection management
VSAM database automation 192
TCP/IP Connection Management
VSAM considerations 21
TCP/IP connections 64, 153
TCP/IP feature 45
TCP/IP stacks 59
local 150
TCP/IP support
setting up 147
TCP/IP tracing 66, 155
256
Installation: Configuring Additional Components
TCP390 policy 65, 154
TCPIP profile 141
VIPADYNAMIC 139
TCPname statement 134
TCPNAME.z, DVIPA.STATS. 142
Telnet server 63, 135, 152
TEMA.SESSACT statement 234
terminal access facility (TAF) 2
terminal access facility (TAF), defining 186
TESTPORT command
critical port monitoring 146
hung listener detection 146
timeout
command to service point 12
connectivity test 10
constants 10
gateway boundary function trace request 11
gateway trace initialization 10
interval 184
line map request 11
NCP boundary function 11
nonpersistent sessions 11
query PSID request 11
remote data retrieval 13
route test 11
RTM collection 12
RTM initialization 12
solicited commands 13
trace initialization 10
trace NCP command 12
VR status request 12
timer events save/restore function, defining 120
Tivoli Business Systems Manager 222
Tivoli Enterprise Console
forwarding messages and alerts 192
Tivoli management region 219
Tivoli NetView for z/OS Enterprise Management Agent
multiple NetView programs in the same LPAR 234
Tivoli NetView program 221
Tivoli Software Information Center xvi
Tivoli technical training xvii
TN3270 server 63, 152
TN3270 service 135
topology 3
trace initialization timeout 10
trace, IP 54, 147
tracing, TCP/IP 66, 155
training, Tivoli technical xvii
translation
CNMSTYLE 225
messages 226
TRANSTBL statement 167, 225
trap-to-alert service 215
traps
DVIPA 140
TSO
command server, customizing 122
TSO command server 122
TSO command servers 57
TSO, reserving REXX environments 111
TSO/E
IRXANCHR table 110
TWS automation 221
TYPE operand
CMDDEF statement 115
typeface conventions xviii
5
U
UNIX
command server, customizing 208
UNIX command server
environment variables 205
initialization script 210
initializing 208
system parameters 203
verifying 210
UNIX command servers 56, 149
UNIX System Services 216
CNMEUNIX 210
environment variables 205
Event/Automation Service 210
NetView considerations 201
system parameters 203
UNIX System Services initialization files
environment variables 205
URL pattern (servlet mapping)
for Web application 105
user group on Yahoo, NetView xviii
user preferences, Web application
overriding 107
setting 107
USRSQLOG task 173
V
variables, notation for xix
verb, defining command 114
verifying
degree of security 97
VIPADYNAMIC TCPIP profile 139, 141
VSAM
allocating 18
buffer allocation, minimum 18
clusters
save/restore 120
database automation 192
performance options, defining 20
VTAM
messages and responses, recording 23
resources, defining 26, 27
VTAMLST 21
W
Web application
initial task displayed 106
override of user preferences 107
performance data, OMEGAMON, configuring the display
of 107
preferences files 107
servlet mapping 105
settings files 107
temporary directory 107
URL pattern 105
Web application server
configuring 104
starting 104
stopping 104
WebSphere 104
Web resources file 130
Web server interface task
definition 104
Web Services Gateway 128
Web Services server
CNMSTYLE statements 128
PROGxx 130
proxy clients, samples 131
resources files 130
security 130
Web XML editing utility 104
web.xml file
editing utility 104
webmenu statements
performance data, OMEGAMON, configuring the display
of 107
WebSphere Enterprise Archive (EAR) file 104
WLM 194
CNMSTYLE 196
NetView subtasks 196
service class name 196
verifying setup 196
workload management 194
X
X.25 monitoring 50
X.25 support 69
XCF groups 161
XCF.GROUPNUM statement 161
XCF.MASTDVIPA statement 160
XCF.proc.PROCSTR statement 160
XCF.RANK statement 157, 160
XCF.TAKEOVER.CLIST statement 161
XCF.TAKEOVER.CONVIPnn statement 161
XCF.TAKEOVER.CONVSNAnn statement 161
XCF.TAKEOVER.NETCONVS statement 161
XML library 129
Y
Yahoo user group, NetView
xviii
Z
z/OS UNIX sockets application 201
znetview_webapp_readme_en.htm file
znvsoa.htm 130
znvsoatx.htm 130
znvwsdl.wsdl 130
znvwsdl1.wsdl 130
znvwsdl2.wsdl 130
104
Index
257
258
Installation: Configuring Additional Components
Program Number: 5697-ENV
Printed in USA
SC31-8874-07