CA Chorus for DB2 Database Management Site

CA Chorus for DB2 Database Management Site
CA Chorus™ for DB2 Database
Management
Site Preparation Guide
Version 04.0.00, Second Edition
This Documentation, which includes embedded help systems and electronically distributed materials (hereinafter referred to as
the “Documentation”), is for your informational purposes only and is subject to change or withdrawal by CA at any time. This
Documentation is proprietary information of CA and may not be copied, transferred, reproduced, disclosed, modified or
duplicated, in whole or in part, without the prior written consent of CA.
If you are a licensed user of the software product(s) addressed in the Documentation, you may print or otherwise make
available a reasonable number of copies of the Documentation for internal use by you and your employees in connection with
that software, provided that all CA copyright notices and legends are affixed to each reproduced copy.
The right to print or otherwise make available copies of the Documentation is limited to the period during which the applicable
license for such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to
certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed.
TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION “AS IS” WITHOUT WARRANTY OF ANY
KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE,
DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST
INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE
POSSIBILITY OF SUCH LOSS OR DAMAGE.
The use of any software product referenced in the Documentation is governed by the applicable license agreement and such
license agreement is not modified in any way by the terms of this notice.
The manufacturer of this Documentation is CA.
Provided with “Restricted Rights.” Use, duplication or disclosure by the United States Government is subject to the restrictions
set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.227-7014(b)(3), as applicable, or
their successors.
Copyright © 2015 CA. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to
their respective companies.
CA Technologies Product References
This document references the following CA Technologies products:
■
CA ACF2™ for z/OS (CA ACF2)
■
CA Chorus™ (CA Chorus)
■
CA Chorus™ for DB2 Database Management (CA Chorus for DB2 Database
Management)
■
CA Chorus™ Infrastructure Management for Networks and Systems (CA Chorus
Infrastructure Management)
■
CA Chorus™ Software Manager (CA CSM)
■
CA Common Services for z/OS (CA Common Services for z/OS)
■
CA OPS/MVS® Event Management and Automation (CA OPS/MVS)
■
CA Detector® for DB2 for z/OS (CA Detector)
■
CA Plan Analyzer® for DB2 for z/OS (CA Plan Analyzer)
■
CA RC/Migrator™ for DB2 for z/OS (CA RC/Migrator)
■
CA RC/Query® for DB2 for z/OS (CA RC/Query)
■
CA RC/Update™ for DB2 for z/OS (CA RC/Update)
■
CA Subsystem Analyzer for DB2 for z/OS (CA Subsystem Analyzer)
■
CA SYSVIEW® Performance Management Option for DB2 (CA SYSVIEW for DB2)
■
CA Top Secret® for z/OS (CA Top Secret)
Contact CA Technologies
Contact CA Support
For your convenience, CA Technologies provides one site where you can access the
information that you need for your Home Office, Small Business, and Enterprise CA
Technologies products. At http://ca.com/support, you can access the following
resources:
■
Online and telephone contact information for technical assistance and customer
services
■
Information about user communities and forums
■
Product and documentation downloads
■
CA Support policies and guidelines
■
Other helpful resources appropriate for your product
Providing Feedback About Product Documentation
If you have comments or questions about CA Technologies product documentation, you
can send a message to [email protected]
To provide feedback about CA Technologies product documentation, complete our
short customer survey which is available on the CA Support website at
http://ca.com/docs.
Documentation Changes
The following documentation updates have been made since the initial 4.0 release:
■
How the Installation Process Works—Added this topic.
■
Getting Started—Expanded the steps in this topic.
■
Software Requirements—Updated requirements for the CA Database Management
Solutions for DB2 for z/OS.
The following documentation updates have been made since the last release of this
documentation:
■
Global—Removed references to manual configuration and the TPDTFEED started
task. This task is no longer used in this release. See Set Up the Performance
Warehouse (see page 38) instead.
■
Software Requirements (see page 19)—Updated requirements.
■
CA Chorus Application Server Requirements (see page 21)—Noted that CA Chorus
now automatically configures the heap memory size. Renamed this server.
■
Run the CA Chorus for DB2 Database Management Discipline Security Job (see
page 23)—Added this new topic, which replaces the manual instructions that were
previously provided for addressing the following security requirements:
–
Installer user ID privileges for USS, z/OS, and DB2
–
User authorization to access USS resources
–
(Optional) Secondary authorization ID use with the EXPLAIN command
–
User authorization to work in CA Chorus
–
Started task permissions
–
PassTicket configuration for user authentication
–
RRSAF authorization
■
Update the CA SYSVIEW for DB2 Configuration (see page 29)—Added information
about updating the security IDs file.
■
How to Enable Object Migration (see page 30)—Added this new scenario. It is now
easier to install and configure the Object Framework Services agent (OFA) and
Object Migrator model JCL. The security requirements have also been simplified to
remove the need to setup a passticket to connect to CA Datacom/AD.
■
Set Up the Performance Warehouse (see page 38)—Added this new section for
providing historical data to the Performance Warehouse and Time Series Facility.
Data is now stored in DB2 tables.
Contents
Chapter 1: Architecture and Installation Overview
9
How the Installation Process Works........................................................................................................................... 10
Getting Started ........................................................................................................................................................... 13
CA Chorus for DB2 Database Management Architecture .......................................................................................... 16
Chapter 2: Addressing General Prerequisites
19
Software Requirements ............................................................................................................................................. 19
CA Chorus Application Server Requirements ............................................................................................................. 21
System Requirements ................................................................................................................................................ 21
Port Requirements ..................................................................................................................................................... 21
Chapter 3: Addressing Security Requirements
23
DB2 User Privileges .................................................................................................................................................... 23
Run the CA Chorus for DB2 Database Management Discipline Security Job ............................................................. 23
Chapter 4: Addressing Configuration Changes
25
Update the Xnet Configuration .................................................................................................................................. 25
Address PassTicket Security Requirements ........................................................................................................ 26
Configure Xnet .................................................................................................................................................... 27
Tune OPSEVENT Health Checks for All Configurations........................................................................................ 29
Update the CA SYSVIEW for DB2 Configuration ......................................................................................................... 29
How to Enable DB2 Object Migration ........................................................................................................................ 30
Override Data Set Allocations ............................................................................................................................. 33
Set Up the Performance Warehouse ......................................................................................................................... 38
CA Detector Tables and Views ............................................................................................................................ 39
CA Subsystem Analyzer Tables and Views .......................................................................................................... 40
CA SYSVIEW for DB2 Tables and Views ............................................................................................................... 41
Appendix A: Improving Performance
45
Appendix B: CA Chorus for DB2 Database Management Installation
Worksheet
47
Contents 7
Chapter 1: Architecture and Installation
Overview
This section contains the following topics:
How the Installation Process Works (see page 10)
Getting Started (see page 13)
CA Chorus for DB2 Database Management Architecture (see page 16)
Chapter 1: Architecture and Installation Overview 9
How the Installation Process Works
How the Installation Process Works
This guide details the tasks that a system programmer and security administrator can
complete before starting the installation, deployment, and configuration tasks that are
described in the Installation Guide. The following diagram provides a high-level
overview of the CA Chorus and discipline installation, deployment, and configuration
process and the guides that you use.
Important! You must use CA Chorus Software Manager to install CA Chorus and its
disciplines.
Important! If you install a discipline, you must deploy and configure it.
Note: For the boxes that indicate work from the discipline Site Preparation Guide,
repeat this step for each discipline that you are installing.
Important! These discipline installation, deployment, and configuration procedures do
not apply to CA Chorus for IMS Database Management. To install this discipline, see the
CA Chorus for IMS Database Management Site Preparation Guide.
10 Site Preparation Guide
How the Installation Process Works
To install, deploy, and configure your CA Chorus and its disciplines, complete the
following steps:
1.
Meet the software, system, port, and other prerequisites as described in the CA
Chorus Site Preparation Guide.
2.
Meet the security requirements as described in the CA Chorus Site Preparation
Guide.
3.
Meet the software, system, port, and other prerequisites as described in the
applicable discipline Site Preparation Guide. Repeat this step for each discipline that
you are installing.
Chapter 1: Architecture and Installation Overview 11
How the Installation Process Works
4.
Meet the security requirements as described in the applicable discipline Site
Preparation Guide. Repeat this step for each discipline that you are installing.
5.
Install CA Chorus and the applicable disciplines using CA CSM as described in the CA
Chorus Installation Guide. This step involves acquiring the CA Chorus software
(transporting to your z/OS system) and installing using SMP/E. The installation
process creates a CSI environment and runs the RECEIVE, APPLY, and ACCEPT
SMP/E steps. The software is untailored.
6.
Deploy CA Chorus and the applicable disciplines using CA CSM or a manual process.
The CA Chorus Installation Guide details both methods.
This step copies the target libraries to another system or LPAR.
Important! For deployments from CA CSM, you must deploy CA Chorus and your
disciplines at the same time. For example, installing CA Chorus, Security, and
Storage, and then deploying only CA Chorus and Security is not supported.
Important! To use the CA CSM Software Configuration Service, CA CSM deployment
is required.
7.
Configure CA Chorus and the disciplines. This step creates customized load
modules, bringing the CA Chorus software to an executable state. You configure the
product using one of the following methods:
CA CSM
This method lets you use the wizard-based CA CSM tools to configure the
product. For this configuration method, a deployment using CA CSM is
required.
The Installation Guide includes the CA Chorus and discipline steps for this
method.
Automated Configuration
This method lets you edit one batch job (ETJICUST) and one configuration file. A
Java program then propagates your changes to the applicable members. You
then manually submit each job. For this option, we recommend that you
configure the CA Chorus Platform and disciplines at the same time.
The Installation Guide includes the CA Chorus and discipline steps for this
method.
8.
12 Site Preparation Guide
(Optional) If your discipline uses CA Chorus File Archive (CFAR), activate your
discipline CFAR. You must first install, deploy, and configure the CA Chorus Platform
and your discipline before you can do so. The Installation Guide includes the steps
for this activation.
Getting Started
Getting Started
This guide details the tasks that a system programmer and security administrator can
complete before starting the installation, deployment, and configuration tasks that are
described in the CA Chorus Installation Guide.
To get started installing and using CA Chorus for DB2 Database Management, complete
the following tasks:
1.
Prepare for installation.
a.
b.
Download the CA Chorus for DB2 Database Management documentation. The
following guides are needed for installation:
■
CA Chorus platform Site Preparation Guide
■
CA Chorus for DB2 Database Management discipline Site Preparation
Guide
■
CA Chorus Installation Guide
■
Security jobs (available from CA Support Online on the CA Chorus for DB2
Database Management product page under Recommended Reading)
Complete the following tasks in the CA Chorus Site Preparation Guide:
■
Read the Architecture and Installation Overview.
■
Meet with a system programmer, storage administrator, and security
administrator and complete the check lists under Pre-Installation Planning.
■
Verify that the required prerequisite software is installed on your system
(see Software Requirements).
■
Verify that the CA CSM DASD requirements for CA Chorus installation are
met as described in CA CSM Dynamic Temporary Storage Requirements
(CA Chorus Installation and Deployment).
■
Determine and record what TCP/IP ports will be used by CA Chorus. These
port values are used later during CA Chorus configuration. See Port
Requirements.
■
Determine and record SMTP mail server information if you want to use
email notification in CA Chorus. See (Optional) SMTP Email Requirements.
■
Verify that maximum number of file descriptors in z/OS UNIX System
Services is at least 64000 as described in USS Parmlib Requirements.
Chapter 1: Architecture and Installation Overview 13
Getting Started
2.
Address security requirements.
a.
Complete the CA Chorus platform security requirements. Download the CA
Chorus platform security job located on CA Support Online at:
http://www.ca.com/us/support/ca-support-online/support-by-product/ca-chor
us.aspx.
Use the downloaded job and the prerequisite checklists from Step 1b as input
to the procedure described in Addressing Security Requirements of the CA
Chorus Site Preparation Guide.
b.
Complete the CA Chorus for DB2 Database Management security requirements.
Download the CA Chorus for DB2 Database Management security job located
on CA Support Online site at:
http://www.ca.com/us/support/ca-support-online/support-by-product/ca-chor
us-for-db2-database-management.asp
http://www.ca.com/us/support/ca-support-online/support-by-product/ca-chor
us.aspx.
Use the downloaded job and the prerequisite checklists completed from Step
1b as input to the procedure described in Addressing Security Requirements in
this guide.
3.
Install CA Chorus platform and apply maintenance as described in the CA Chorus
Installation Guide.
4.
Verify installation of the required CA Database Management Solutions for DB2 for
z/OS, including FMID EU9/CHRDBM. See Software Requirements in this guide.
5.
Apply maintenance for the CA Database Management Solutions for DB2 for z/OS.
CA Chorus for DB2 Database Management requires installation of all PTFs for the
backend products.
6.
Update configuration of the CA Database Management Solutions for DB2 for z/OS
for CA Chorus for DB2 Database Management.
Complete each section in Addressing Configuration Changes in this guide. Changes
are needed for:
14 Site Preparation Guide
■
Xnet
■
CA SYSVIEW for DB2
■
Object migration
■
(Optional) Performance warehouse
7.
Install CA Chorus for DB2 Database Management discipline and apply maintenance
as described in the CA Chorus Installation Guide.
8.
Deploy CA Chorus and CA Chorus for DB2 Database Management as described in
the CA Chorus Installation Guide.
Getting Started
9.
Configure CA Chorus and CA Chorus for DB2 Database Management discipline as
described in the CA Chorus Installation Guide.
a.
Follow the steps in Configure Your Product Automatically (Auto Config). This
step creates several jobs that are submitted in the next step.
b.
Submit jobs in the order documented in Submit CA Chorus and Discipline Jobs
(Auto Config). The CA Chorus Application Server is started at the end of this
step.
c.
Verify the CA Chorus Application Server by following the instructions in Verify
the Installation and Configuration.
d.
Review the Post-Installation Considerations.
10. Configure your workspace to add discipline specific dashboards, policies, and
metrics. Detailed information about configuring your workspace is provided in the
CA Chorus Product Guide and the CA Chorus for DB2 Database Management User
Guide.
Chapter 1: Architecture and Installation Overview 15
CA Chorus for DB2 Database Management Architecture
CA Chorus for DB2 Database Management Architecture
CA Chorus for DB2 Database Management lets you perform various database
administration and performance management operations on mainframe databases from
a single console.
The following diagram details the architecture and data flow for the discipline
components:
16 Site Preparation Guide
CA Chorus for DB2 Database Management Architecture
This diagram shows the following processing:
■
The CA Database Management Solutions for DB2 for z/OS have been installed and
configured for the ISPF interface. CA Chorus for DB2 Database Management
interfaces directly with these products and components to manage your DB2
environment:
CA Detector
Optimizes performance of applications and databases while minimizing DB2
resource consumption by identifying dynamic and static SQL statements and
DB2 applications that impact performance.
CA Plan Analyzer
Analyzes SQL and offers SQL performance improvement recommendations and
management services.
CA RC/Migrator
Automates the processing of migrating and altering DB2 objects while
maintaining the integrity of the DB2 environment.
CA RC/Query
Eases catalog navigation with a comprehensive DB2 catalog management
facility for querying, evaluating, analyzing, and maintaining the DB2 subsystem.
CA RC/Update
Provides DB2 object creation and alteration capabilities, DB2 data related edit,
compare, and copy functions, and SQL testing and execution. You can also
insert, delete, and modify data in referential structures.
CA Subsystem Analyzer
Analyzes and tunes DB2 subsystems proactively, conserving DB2 resources and
preventing DB2 subsystem performance problems.
CA SYSVIEW for DB2
Monitors DB2 system and application performance problems in real-time so
they can fix critical issues before they impact service levels. Historical
performance trending provides DBAs data that is necessary for proactive
performance management.
–
General functions:
–
Batch Processor
–
Object Framework Services (OFS)—Performs DB2 system catalog access for
CA Chorus for DB2 Database Management.
–
CA Chorus DBA Services (FMID EU9/CHRDBM) (OFS agent, OFA)—Services
requests from the CA Database Management Solutions for DB2 for z/OS on
behalf of user requests from other products like CA Chorus for DB2
Database Management. OFA executes as a started task in its own address
space and works with the Xmanager and Xnet address spaces.
Chapter 1: Architecture and Installation Overview 17
CA Chorus for DB2 Database Management Architecture
Product Agents
Translates communications among CA Chorus, CA Chorus for DB2 Database
Management, and CA Database Management Solutions for DB2 for z/OS products.
Xmanager
Establishes and controls an execution environment for all products. Xmanager
(Execution Manager) executes as a started task in its own address space by all
products on a single LPAR. If you have products that are installed on multiple LPARs,
repeat the customization steps on each LPAR.
Xnet
Provides a shared communications subsystem for all CA Database Management
Solutions for DB2 for z/OS. Xnet (Execution Manager Networking) executes as a
started task in its own address space. Xnet works with the Xmanager address space
for CA Database Management Solutions for DB2 for z/OS.
CA Chorus Application Server
Hosts the CA Chorus application server.
Time Series Facility (TSF)
Stores the data that is collected and provided from CA Detector.
DB2 for z/OS
Indicates the IBM DB2 for z/OS version that you are using with CA Chorus and CA
Chorus for DB2 Database Management.
18 Site Preparation Guide
Chapter 2: Addressing General
Prerequisites
This section contains the following topics:
Software Requirements (see page 19)
CA Chorus Application Server Requirements (see page 21)
System Requirements (see page 21)
Port Requirements (see page 21)
Software Requirements
The following software is required for CA Chorus for DB2 Database Management:
■
CA Technologies software:
–
CA Chorus Version 4.0
For initial site installations, you install CA Chorus and the disciplines at the
same time as described in the CA Chorus Installation Guide.
When you are installing a discipline into an existing CA Chorus instance,
confirm that the version of your discipline matches the CA Chorus version.
Note: For more information about installing CA Chorus, see the CA Chorus Site
Preparation Guide and CA Chorus Installation Guide.
Chapter 2: Addressing General Prerequisites 19
Software Requirements
–
The following CA Database Management Solutions for DB2 for z/OS at Release
16.0, Release 17.0, or Release 18.0:
Important! Apply all current CA Chorus FIXCAT maintenance for these
products. The FIXCAT label is
CA.ProductInstall-RequiredService.CA-Mainframe-Chorus.*, where * indicates
the version of CA Chorus that you are installing.
■
CA Detector
■
CA Plan Analyzer
■
CA RC/Migrator
■
CA RC/Query
■
CA RC/Update
■
CA Subsystem Analyzer
■
CA SYSVIEW for DB2
■
General components: Xmanager, Xnet. Batch Processor, Object Framework
Services (OFS), and CA Chorus DBA Services (FMID EU9/CHRDBM)
Important! Install FMID EU9/CHRDBM after the installation of CA Chorus
Version 4.0.
Note: If CA Chorus Infrastructure Management is installed, CA SYSVIEW for
DB2, Xmanager, and Xnet are already installed and configured. For more
information about installing these products and components, see the CA
Database Management Solutions for DB2 for z/OS installation documentation.
For more information about updating the configuration of these products to
integrate with CA Chorus for DB2 Database Management, see the later
chapters in this guide.
■
IBM software:
–
–
A supported IBM DB2 version based on the release of the CA Database
Management Solutions for DB2 for z/OS that you are running:
■
For Release 16.0 or Release 17.0, IBM DB2 9 or 10.
■
For Release 18.0, IBM DB2 10 or 11.
IBM Resource Recovery Services (RRS) for z/OS to manage the Resource
Recovery Services Attachment Facility (RRSAF)
Note: RRSAF is the DB2 attachment facility that CA Chorus for DB2 Database
Management uses. For more information about implementing RRS for your
DB2 systems, see the IBM Resource Recovery Services documentation.
20 Site Preparation Guide
CA Chorus Application Server Requirements
CA Chorus Application Server Requirements
Confirm that your site meets the following requirements:
Real storage
200 MB heap memory for CA Chorus for DB2 Database Management plus 2450 MB
heap memory for CA Chorus.
Note: If all disciplines are installed, 3150 MB is required. CA Chorus automatically
configures the heap memory size based on the disciplines that you install. This
configuration is done during the CA CSM Software Configuration Service (SCS) or in
CETJJCL(ETJI0150).
System Requirements
Confirm that your site meets the following system requirements:
Disk
CA Chorus for DB2 Database Management requires approximately 251 tracks.
Note: The download and REL files are automatically deleted after the installation
completes successfully.
Processor
CA Chorus uses a JavaVM environment on z/OS. So, we strongly recommend that
you use a zIIP specialty processor for the best performance and better use of
resources.
Port Requirements
Each Xnet (execution manager networking) server that you are running, requires a
TCP/IP port specification and a corresponding connection definition in CA Chorus for
DB2 Database Management.
The listener process in the Xnet communications server uses the port to accept
connections from the data source handler (DSH) in CA Chorus for DB2 Database
Management to Xnet. Xnet provides a shared communications subsystem for all CA
Database Management solutions for DB2 for z/OS. When Xnet is started, it binds the
port to a listening socket and it accepts connections from CA Chorus clients.
Chapter 2: Addressing General Prerequisites 21
Port Requirements
The port number is specified in the PXNPROC JCL in your_db2tools_hlq.CDBASAMP. This
value is typically customized during post-installation processing of the installed CA
Database Management Solutions for DB2 for z/OS. Use this same port value to define
the DB2 subsystem connections during CA Chorus for DB2 Database Management
configuration.
Confirm that the ports you intend to use are available by consulting with your network
management team.
More information:
Update the Xnet Configuration (see page 25)
22 Site Preparation Guide
Chapter 3: Addressing Security
Requirements
This section contains the following topics:
DB2 User Privileges (see page 23)
Run the CA Chorus for DB2 Database Management Discipline Security Job (see page 23)
DB2 User Privileges
CA Chorus for DB2 Database Management users need EXECUTE authority in DB2 on the
requisite CA Database Management Solutions for DB2 for z/OS product plans:
■
General functions (batch processor, object framework services)
■
Chorus OFS agent
■
CA Detector
■
CA Plan Analyzer
■
CA RC/Migrator
■
CA RC/Query
■
CA RC/Update
■
CA Subsystem Analyzer
■
CA SYSVIEW for DB2
To assign these privileges, use the Product Authorizations facility (option A) on the CA
Database Management for DB2 for z/OS Main Menu.
Run the CA Chorus for DB2 Database Management Discipline
Security Job
The E3KI095x security jobs consolidate the security requirements (installer, user,
secondary, started task, PassTicket, RRSAF) for the CA Chorus for DB2 Database
Management discipline. Use these jobs to authorize users to work in the CA Chorus for
DB2 Database Management discipline and address other security requirements.
Chapter 3: Addressing Security Requirements 23
Run the CA Chorus for DB2 Database Management Discipline Security Job
Follow these steps:
24 Site Preparation Guide
1.
Log in to CA Support Online (CSO) and go to the CA Chorus for DB2 Database
Management product page under Knowledge Center.
2.
Go to Recommended Reading under Content Summary and download one of the
following security jobs based on the security product in use at your site and the
product release:
■
E3KI095A for CA ACF2
■
E3KI095I for CA Top Secret
■
E3KI095R for IBM RACF
3.
Customize the job for your environment as described within the JCL and save your
changes.
4.
Submit the job. The expected return code is zero.
5.
Review the output of the job for verification that the security definitions have been
defined successfully.
Chapter 4: Addressing Configuration
Changes
This chapter describes the configuration tasks that must be done to integrate the
back-end products with CA Chorus for DB2 Database Management.
If CA Chorus Infrastructure Management is installed, the following tasks have already
been completed:
■
Update the Xnet configuration.
■
Update the CA SYSVIEW for DB2 configuration.
Update the Xnet Configuration
Execution Manager Networking (Xnet) executes as a started task in its own address
space. Xnet works with the Execution Manager (Xmanager) address space for the CA
Database Management Solutions for DB2 for z/OS to provide a shared communications
subsystem. The Xnet configuration must be updated for use with CA Chorus for DB2
Database Management to enable communication between the CA Database
Management Solutions for DB2 for z/OS and CA Chorus for DB2 Database Management.
Note: Verify that Xnet customization as described in the CA Database Management
Solutions for DB2 for z/OS installation documentation has been completed.
Important! PassTicket configuration for CA Chorus for DB2 Database Management must
be completed before you update the Xnet configuration.
Follow these steps:
1.
Address PassTicket security requirements (see page 26).
2.
Update the Xnet configuration (see page 27).
3.
Tune OPSEVENT health checks for all configurations (see page 29).
Chapter 4: Addressing Configuration Changes 25
Update the Xnet Configuration
Address PassTicket Security Requirements
All of the products that use Xnet send a z/OS user ID to Xnet when they first establish
their TCP/IP connection to Xnet. This z/OS user ID is expected to be a valid user ID that is
properly defined to the security subsystem of the z/OS system where Xnet is executing.
All of the external products also send a PassTicket value that use can be used as a
substitute for the current password that is associated with the z/OS user ID. The
PassTicket value is:
■
Generated by the security subsystem on the z/OS system where the external
product is executing.
■
Authenticated by the security subsystem on the z/OS system where Xnet is
executing.
Xnet and the external products often reside on the same z/OS system but this is not a
requirement.
Several security subsystem definitions must be established before the security
subsystem can generate or authenticate a PassTicket value. These definitions are
typically created as part of the installation procedures for the external product.
PassTickets are always generated for a specific application and the security subsystem
requires the definition of an APPL name to represent the application. PassTicket
generation requires that you also define a secret encryption key value for that APPL
name within the security subsystem. The PassTicket value that the security subsystem
generates creates a substitute password that:
■
Combines elements of the user ID name, the APPL name, and the current time and
date
■
Is encrypted using the secret encryption key value
The substitute password is:
■
Valid for only a short period of time
■
Only recognizable by a product that references the same APPL name when it calls
its local security subsystem to authenticate the user ID and PassTicket value.
If the generating and authenticating security subsystems reside on different z/OS
systems, the secret encryption key value that is defined for the APPL name on each
system must be the same.
26 Site Preparation Guide
Update the Xnet Configuration
When all of the required security subsystem definitions are completed, Xnet can be
updated to use PassTicket values for user ID authentication. To update Xnet, edit the
PASSNAME parameter in the PXNPARM member in the CDBAPARM data set. The Xnet
PASSNAME parameter specifies the APPL name that has been selected and configured
for PassTicket generation and authentication in the security subsystem or subsystems.
Important! Enable the Xnet PASSNAME parameter before the product begins sending
PassTicket values for user authentication. Failure to enable the Xnet PASSNAME can
result in the suspension of user IDs by the security subsystem due to PassTicket
authentication failures.
Important! Xnet supports a single APPL name that is specified using the PASSNAME
parameter. If Xnet is interfacing to more than one product outside the CA Database
Management Solutions for DB2 for z/OS, a conflict can arise with respect to the required
APPL name. For example, CA Chorus for DB2 Database Management can be installed
using the APPL name CHORWEBS and CA SYSVIEW Performance Management can be set
up to use the APPL name DB2TOOLS. If there is a conflict, the products must be changed
to use a common APPL name that can be specified in the Xnet PASSNAME parameter.
Configure Xnet
CA Chorus for DB2 Database Management uses the Xnet execution space (XES) feature
and this feature must be enabled in the Xnet PXNPARM member.
CA Chorus for DB2 Database Management also provides an interface component that is
known as the data source handler (DSH). The DSH can interface the CA Chorus
Application Server to any number of Xnet servers that may be running on the same, or
different, z/OS systems. To identify each Xnet to be included, the DSH uses the
db2tools.cfg file that is prepared during CA Chorus for DB2 Database Management
configuration.
Chapter 4: Addressing Configuration Changes 27
Update the Xnet Configuration
To configure Xnet for use with CA Chorus for DB2 Database Management, complete the
following steps:
1.
Edit the Xnet PXNPARM member in the your_db2tools_hlq.CDBAPARM data set to
remove the comment indication (*) from the:
■
PASSNAME parameter.
The PASSNAME value specifies the application name (APPL) that is used for
PassTicket support. This value is used when CA Chorus for DB2 Database
Management user logins are verified. You may need to change the actual
application (APPL) name that is specified in the PASSNAME parameter to match
the APPL name that is specified in the db2tools.cfg file entry. See Step 4.
■
Set of XES-related statements.
Note: The INITPARM DD statement in the Xnet JCL procedure selects the PXNPARM
startup parameter file.
2.
Set port, tcp, and xman ID in the Xnet started task (PXNPROC in
your_db2tools_hlq.CDBASAMP).
Note: If you are using an Xmanager value of 0000 in the started task procedure
(PTXMAN), update the XMANID parameter to the release version. For example,
specify XMANID=1800 for Version 18.0 of the CA Database Management Solutions
for DB2 for z/OS.
3.
Restart each Xnet configuration:
S PXNPROC
A message indicates that the Xnet started task has initialized successfully.
28 Site Preparation Guide
Update the CA SYSVIEW for DB2 Configuration
Tune OPSEVENT Health Checks for All Configurations
Xnet performs a health check every five (5) minutes. By default, Xnet checks a number
of key facilities and then reports a NORMAL, WARNING, or PROBLEM status to the Xnet
JESMSGLG and also to the CA OPS/MVS product, if it is available. Not all of the key
facilities being checked are required in every configuration. If unnecessary key facilities
are checked, inaccurate WARNING or PROBLEM reports can be generated even though
the configuration is correct and operating properly.
To prevent these unnecessary reports, we recommend that you tune the OPSEVENT
health checks that are described in the PXNPARM member in the CDBAPARM data set.
The goal of the tuning is to test all of the key facilities that should be operational in your
Xnet configuration periodically so that the health reporting is NORMAL when your
configuration is completely operational. Then, using the periodic report messages that
are logged, it will be possible to identify the approximate time when a WARNING or
PROBLEM condition first began, review other system events around that time, track
down the cause, and effect a remedy.
All of the health checks are appropriate when Xnet is interfacing with CA Chorus for DB2
Database Management. Use the comments in the PXNPARM member to help identify
specific checks that should be disabled when Xnet is interfacing with other products.
One of the checks verifies the correct operation of the PassTicket services that rely on
the PASSNAME parameter using the user ID that is assigned to the Xnet started task.
This check simulates a "log in" operation using a PassTicket. In some security subsystem
definitions, user IDs that are assigned to started tasks are often assigned a special
property that prevents the started task user IDs from being used in "log in" operations.
When this occurs, specify a valid user ID that can "log in" instead of the Xnet started
task user ID.
Update the CA SYSVIEW for DB2 Configuration
To enable communication between CA Chorus for DB2 Database Management and CA
SYSVIEW for DB2 data collectors, the CA SYSVIEW for DB2 configuration must be
updated.
Note: CA SYSVIEW for DB2 data collectors are set up and configured during the
post-installation processing of CA SYSVIEW for DB2. For more information about the set
up and configuration of CA SYSVIEW for DB2, see the CA Database Management
Solutions for DB2 for z/OS installation documentation and the CA SYSVIEW for DB2
System Reference Guide. For CA SYSVIEW for DB2 best practices, see the CA Database
Management Solutions for DB2 for z/OS Best Practices Guide.
Chapter 4: Addressing Configuration Changes 29
How to Enable DB2 Object Migration
Follow these steps:
1.
Update your CA SYSVIEW for DB2 data collector initialization parameters to specify
XNETAGT=YES for each DB2 subsystem in your CA Chorus configuration. The data
collector initialization parameters reside in IDDCPRMS in
your_db2tools_hlq.SOURCE.
The Xnet agent subtask is started during CA SYSVIEW for DB2 initialization. This
subtask periodically attempts to connect to its associated Xmanager and Xnet pair
using the XMANID value that CA SYSVIEW for DB2 has obtained. CA SYSVIEW for
DB2 obtains the XMANID from the Xmanager global parameters in the SETUPxx
parmlib member in your_db2tools_hlq.CDBAPARM.
Note: For more information about using Xmanager and Xnet, see the CA Database
Management Solutions for DB2 for z/OS shared common documentation.
2.
If the CA SYSVIEW for DB2 security facility is used to control access to CA SYSVIEW
for DB2 and specific menus, add the following line to the SECURITY IDS=()
definition:
(TYPE=USER,CHORTHD,*,SYSADM),
The ID that is used for CHORTHD must be given the same access as a normal user to
CA SYSVIEW for DB2. CHORTHD is set during installation and configuration of CA
Chorus.
Note: For more information about installing CA Chorus, see the CA Chorus Site
Preparation Guide and the CA Chorus Installation Guide.
3.
Ensure that the STARTUP member contains the DSQxxxx requests that are included
by default when the .SOURCE library in CA SYSVIEW for DB2 is populated during the
post-installation processing.
How to Enable DB2 Object Migration
Before you can use the Object Migrator function in CA Chorus for DB2 Database
Management to migrate DB2 objects, perform the tasks in the following procedure
manually outside of CA CSM. This procedure describes how to customize the Object
Framework Services Agent (OFA) that is used by the Object Migrator and DBA Command
Manager functions in CA Chorus for DB2 Database Management.
Note: This configuration is not required for integration with CA Chorus Infrastructure
Management.
30 Site Preparation Guide
How to Enable DB2 Object Migration
Follow these steps:
1.
Confirm that at least one CA RC/Migrator utility model ID exists.
Note: The @DEFAULT model is created during CA RC/Migrator post-installation DB2
catalog customization. You can create this model and additional models using the
CA RC/Migrator profile option (PROF). Select Utility Model Services, and then use
the template (T) option to create a model using an existing model as a template. For
more information about creating models, see the CA RC/Migrator User Guide.
2.
3.
4.
Based on the version of the CA Database Management Solutions for DB2 for z/OS
that you are running at your site, complete either of the following bullet items to
configure the OFA:
■
If you are running Version 18.0, use ISPF panels during post-installation
processing to configure OFA as described in the CA Database Management
Solutions for DB2 for z/OS Installation Guide.
■
If you are running Version 17.0 or Version 16.0, complete the remaining steps
in this procedure manually, starting at Step 3. Ensure all OFA-related
maintenance has been applied before completing these steps.
Allocate a configuration PDS with the following attributes:
■
Tracks: 2
■
Record format: FB
■
Record length: 80
■
Block size: 27920
Define global configuration parameters:
■
Create the default global configuration member (@DEFAULT) in the OFA
configuration PDS and add the following JCL:
<JOB CARD>
//jobcard JOB (ACCT INFO),'job title',CLASS=A,MSGCLASS=X,
//
MSGLEVEL=(1,1),REGION=0M,NOTIFY=userid
</JOB CARD>
<MODEL4>
MODEL4 model ID
</MODEL4>
<MODEL4C>
MODEL4C creator
</MODEL4C>
■
Replace the italicized text with site-specific values. Include the desired JOB
statement for z/OS batch jobs (<JOB CARD>, </JOB CARD), the model ID or
name (<MODEL4>, </MODEL4), and creator (<MODEL4C>, </MODEL4C>), and
save your changes.
Chapter 4: Addressing Configuration Changes 31
How to Enable DB2 Object Migration
Important! By default, the DBA Command Manager and Object Migrator
functions create temporary data sets using the TSO PREFIX of each user as the
high-level qualifier. You can override the default settings on a specific LPAR or
on all systems. For more information about overriding the default settings, see
Override Data Set Allocations (see page 33).
5.
(Optional) Specify alternate high-level qualifiers for use with temporary data sets:
■
Create a member in the OFA configuration PDS for each Object Migrator user
that is named the same as their user ID. You can use the @DEFAULT member in
the OFA configuration PDS as a template.
Note: Use the JOB statement, model name (ID), and creator values for
overriding global settings. The model ID and creator must match the members
that you create. The creator specifies the member creator user ID.
■
Add the following tags to specify an LPAR name and the high-level qualifier to
be used with the creation of temporary data sets for this user:
<SYSTEM:lpar>
<PREFIX>
hlq;
</PREFIX>
</SYSTEM:lpar>
Note: The hlq must be terminated with a semi-colon.
For examples on overriding the default settings, see Override Data Set
Allocations (see page 33).
When you are done adding members, the members appear in the configuration
data set members list. These members are used during DB2 object migration when
the migration is submitted for analysis.
6.
Update the OFAPROC started task JCL as follows and save your changes:
Important! When complete, you must recycle the agent to enable these changes.
Note: The OFAPROC started task needs READ permission for BPX.SERVER. If the
EZB.STACKACCESS resource is protected, the appropriate READ permissions are
needed for the user ID that is associated with the OFAPROC started task and the
users requesting access to the Object Migrator function.
32 Site Preparation Guide
a.
Copy the OFAPROC sample JCL procedure in your_db2tools_hlq.CDBASAMP to
a z/OS system procedure library that is available to the z/OS START command.
b.
Edit the new member as follows:
■
Specify a valid JOB statement.
■
Add MSGCLASS or CLASS.
■
Supply the target library data set name prefix (TGTPFX) .
■
(Optional) Use a unique name for the agent by changing the value that is
specified for the procedure ID. By default, XMANID is specified in
hlq.CDBAPARM(SETUPxx).
How to Enable DB2 Object Migration
■
Add the following DD statement:
//CFGFILE
c.
DD DISP=SHR,DSN=config.om.pds
(Optional) If you want to direct output to a data set instead of SYSOUT (the
default), add the following DD statements for the sequential log data sets and
allocate the log data sets manually with record format VB, record length 1028,
block size 6144, cylinders 20:
//LOGGER1
//LOGGER2
DD DISP=SHR,DSN=hlq.OFALOG1
DD DISP=SHR,DSN=hlq.OFALOG2
Note: To turn off the logging capability for OFAPROC, contact CA Support for
instructions.
Override Data Set Allocations
To override the default data set allocations for the Object Migrator and the DBA
Command Manager for DB2, specify an alternate high-level qualifier in the default or
user-specific configuration parameters. You can override the default settings on a
specific LPAR or on all systems by specifying an alternate high-level qualifier such as a
specific TSO prefix, the CA Chorus user ID, any constant, or a combination of a constant
and a user ID or TSO prefix.
The following table describes the order of precedence processing (first to last) that
occurs when an alternate high-level qualifier (hlq) is specified:
Order of precedence in which the high-level qualifier is used:
Order of precedence: 1 (First) to 4 (Last)
Order of precedence in which the
high-level qualifier is used:
1
Individual member – specific LPAR
2
@DEFAULT member – specific LPAR
3
Individual member – SYSTEM: ALL
4
@DEFAULT member – SYSTEM: ALL
The following examples demonstrate how this processing works.
Chapter 4: Addressing Configuration Changes 33
How to Enable DB2 Object Migration
Example for @DEFAULT Member
In this example, the following entries are defined in the @DEFAULT member:
■
SYSTEM: ALL
■
SYSTEM: LPAR1
There are no entries defined in individual user members.
The following table shows the LPAR on which execution occurs and the HLQ value that is
used in the @DEFAULT member:
Execution LPAR
HLQ Used
LPAR1
HLQ defined for LPAR1
LPAR2
(represents any LPAR other than LPAR1
defined in the @DEFAULT member)
HLQ defined for ALL.
Example 1 for individual member (Case 1)
In this example, there are no entries defined in the @DEFAULT member.
The following entries are defined in individual user members:
■
SYSTEM: ALL
■
SYSTEM: LPAR1
The following table shows the LPAR on which execution occurs and the HLQ value that is
used in the individual user member:
LPAR in which execution happens
HLQ used
LPAR1
HLQ defined for LPAR1 in the individual
user member
LPAR2
HLQ defined for ALL in the individual user
(any LPAR other than LPAR1 defined in the member
individual user member)
34 Site Preparation Guide
How to Enable DB2 Object Migration
Example 2 for individual member (Case 2)
In this example, the following entries are defined in the @DEFAULT member:
■
SYSTEM: ALL
■
SYSTEM: LPAR2
The following entries are defined in individual user members:
■
SYSTEM: ALL
■
SYSTEM: LPAR1
The following table shows the LPAR on which execution occurs and the HLQ value that is
used:
LPAR in which execution happens
HLQ used
LPAR1
HLQ defined for LPAR1 in the individual
user member
LPAR2
HLQ defined for LPAR2 in the @DEFAULT
member
LPAR3
HLQ defined for ALL in the individual user
member
(any LPAR other than LPAR1 and LPAR2
defined in the @DEFAULT member and
the individual user member)
Chapter 4: Addressing Configuration Changes 35
How to Enable DB2 Object Migration
Example: How to Specify Different Allocation Parameters for Different LPARs
This example shows how to use different allocation parameters for different LPARs.
Edit the @DEFAULT member from the OFA configuration file (PDS) and add the
following values:
<SYSTEM:ALL>
<PREFIX>
%USERID;
</PREFIX>
</SYSTEM:ALL>
<SYSTEM:LPAR1>
<PREFIX>
%TSOPREFIX.LPAR1
</PREFIX>
</SYSTEM:LPAR1>
During run time, the value %TSOPREFIX.LPAR1.* is used for requests coming from LPAR1
and the value %USERID.* is used for requests coming from all other systems/LPARs.
You can also provide system/LPAR-specific configuration by manually editing the
@DEFAULT member or the individual member to add the following control statements:
<SYSTEM:ALL>
<PREFIX>
%TSOPREFIX;
</PREFIX>
</SYSTEM:ALL>
Note: Replace ALL in the <SYSTEM:ALL> and </SYSTEM:ALL> tags with the same specific
LPAR, for example, LPAR1.
36 Site Preparation Guide
How to Enable DB2 Object Migration
Example: Override Data Set Allocations when the Configuration File contains the
@DEFAULT and User ID Members
These examples show how to override the prefix values that are based on the
originating system during data set allocations. To do so, add <SYSTEM> and <PREFIX>
control cards to the @DEFAULT and user ID members:
■
The @DEFAULT member contains the following:
<SYSTEM:SYS1>
<PREFIX>
MCA11
</PREFIX>
</SYSTEM:SYS1>
■
The user ID member contains the following:
<SYSTEM:SYS2>
<PREFIX>
MCOE
</PREFIX>
</SYSTEM:SYS2>
During run time, the value MCA11.ETJ.* is used for requests coming from SYS1 and the
value MCOE.ETJ.* is used for requests coming from SYS2.
We recommend that you repeat the previous lines (from <SYSTEM:ALL> to
</SYSTEM:ALL>) and customize as needed for a specific LPAR.
Example: Override Data Set Allocations Using a Different High-Level Qualifier
This example shows how to use a site-specific high-level qualifier during data set
allocations for all users:
CHORUS.TEMP
Example: Override Data Set Allocations Using the MYID.HLQ Prefix
This example shows how to use a constant second node applicable for all users while
the first node is replaced with the user ID:
%USERID..CATECH
During run time, values in the @DEFAULT member are ignored. Instead, the value
MYID.HLQ.ETJ* is used. If this control statement is added to the @DEFAULT member,
the value MYID.HLQ.ETJ* is used during run time if no user ID member is specified.
Chapter 4: Addressing Configuration Changes 37
Set Up the Performance Warehouse
Example: Override Data Set Allocations Using the CATECH.%TSOPREFIX Prefix
This example shows how to use a constant first node applicable for all users while the
second node is replaced with the TSOPREFIX value of the user:
CATECH.%TSOPREFIX
Example: Override Data Set Allocations Using the %USERID.B Prefix
This example shows how to append a constant to the user ID and use the resulting
string as the prefix:
%USERID.B
Set Up the Performance Warehouse
You can access existing CA Detector, CA Subsystem Analyzer, and CA SYSVIEW for DB2
performance data from the Performance Warehouse in the CA Chorus for DB2 Database
Management Investigator, and then chart that data using the CA Chorus Time Series
Facility (TSF). The Performance Warehouse requires the data to be loaded into the
product tables and then mapped to the Performance Warehouse folders using views on
each desired DB2 subsystem.
Note: This configuration is not required for integration with CA Chorus Infrastructure
Management.
Important! This step must be performed manually outside of CA CSM.
Follow these steps:
38 Site Preparation Guide
1.
Start collection activity as described in the CA Detector, CA Subsystem Analyzer,
and CA SYSVIEW for DB2 product-specific documentation.
2.
Verify that the following product tables have been defined on the desired DB2
subsystems. These DB2 objects are created during post-installation processing of
the CA Database Management Solutions for DB2 for z/OS and the DDL is located in
your_db2_hlq.SPFSLIB members.
■
PDTDDL (for CA Detector)
■
PSADDL (for CA Subsystem Analyzer)
■
ARCDDL (for CA SYSVIEW for DB2)
Set Up the Performance Warehouse
3.
Define the CA Chorus for DB2 Database Management Investigator Performance
Warehouse DB2 views using the following members in your_db2_hlq.CDBASKL0:
(modify as needed at your site)
■
CHRSDDL1 (for CA Detector) (see page 39)
■
CHRSDDL2 (for CA Subsystem Analyzer) (see page 40)
■
ARCVW418 (for CA SYSVIEW for DB2) (see page 41)
Note: These views are not part of the CA Database Management Solutions for DB2
for z/OS post-installation process. Use the CA Interactive SQL facility (ISQL) or IBM
SPUFI under DB2I to execute these members. Perform this step on each DB2
subsystem where archived performance data is stored and desired to be accessible
from the CA Chorus for DB2 Database Management Investigator Performance
Warehouse.
4.
Load the desired product data:
■
For CA Detector, follow the instructions under Using Batch Reporting on CA
Detector for information about how to unload collection data and load
collection data into DB2 tables.
■
For CA Subsystem Analyzer, follow the instructions under Using Batch
Reporting on CA Subsystem Analyzer for information about how to unload
collection data and load collection data into DB2 tables.
■
For CA SYSVIEW for DB2, follow the instructions for archiving DB2 performance
data in the CA SYSVIEW for DB2 System Reference Guide.
For CA SYSVIEW for DB2 documentation, use the following bookshelf:
CA Database Management Solutions Version 18.0.00 for DB2 for z/OS
Bookshelf
(https://support.ca.com/cadocs/7/CA%20Database%20Management%20Soluti
ons%20Version%2018%200%2000%20for%20DB2%20for%20z%20OS-ENU/Boo
kshelf.html)>
(http://wiki. ca.com/ db2r eport )
CA Detector Tables and Views
The following table shows the CA Detector application performance tables and views
that you can map to the Application category in the Performance Warehouse in CA
Chorus for DB2 Database Management:
Note: Table DDL is located in your_db2_hlq.SPFSLIB(PDTDDL). View DDL is located in
your_db2_hlq.SPFSLIB(CHRSDDL1). The CA Detector PDT_STANDARD_# table is mapped
by many views per the record type.
Category
Table
View
Plans
PTI.PDT_STANDARD_#
PTI.PDT_STANDARD_PLAN_VW
Chapter 4: Addressing Configuration Changes 39
Set Up the Performance Warehouse
Category
Table
View
Programs
PTI.PDT_STANDARD_#
PTI.PDT_STANDARD_PGM_VW
Package
PTI.PDT_STANDARD_#
PTI.PDT_STANDARD_PKGE_VW
Packages
PTI.PDT_STANDARD_#
PTI.PDT_STANDARD_PKGS_VW
Packages, group
PTI.PDT_STANDARD_#
PTI.PDT_STANDARD_PKGP_VW
SQL statements
PTI.PDT_STANDARD_#
PTI.PDT_STANDARD_STMT_VW
Dynamic SQL statements
PTI.PDT_STANDARD_#
PTI.PDT_STANDARD_DYNS_VW
SQL statement object
PTI.PDT_OBJECT_#
PTI.PDT_OBJECT_VW
SQL text
PTI.PDT_STANTEXT_#
PTI.PDT_STANTEXT_VW
SQL error activity
PTI.PDT_SQLERROR_#
PTI.PDT_SQLERROR_VW
SQL error activity, SQL text
PTI.PDT_ERRORTXT_#
PTI.PDT_ERRORTXT_VW
SQL error activity, SQL host
variables
PTI.PDT_ERRORVAR_#
PTI.PDT_ERRORVAR_VW
SQL exception activity
PTI.PDT_DYNAMREQ_#
PDI.PDT_DYNAMREQ_VW
SQL exception activity, SQL
text
PTI.PDT_DYNAMTXT_#
PTI.PDT_DYNAMTXT_VW
SQL exception activity, SQL
host variables
PTI.PDT_HOSTVARS_#
PTI.PDT_HOSTVAR_VW
CA Subsystem Analyzer Tables and Views
The following table shows the CA Subsystem Analyzer subsystem performance tables
and views that you can map to the Subsystem Performance category in the Performance
Warehouse in CA Chorus for DB2 Database Management:
Note: Table DDL is located in your_db2_hlq.SPFSLIB(PSADDL). View DDL is located in
your_db2_hlq.SPFSLIB(CHRSDDL2).
Category
Table
View
Buffer pool I/O activity
PTI.PSA_BP_#
PTI.PSA_BP_VW
Database I/O activity
PTI.PSA_DB_#
PTI.PSA_DB_VW
Storage volume I/O activity
PTI.PSA_VOL_#
PTI.PSA_VOL_VW
40 Site Preparation Guide
Set Up the Performance Warehouse
CA SYSVIEW for DB2 Tables and Views
The following table shows the CA SYSVIEW for DB2 application and subsystem
performance tables and views that you can map to the Application and Subsystem
categories in the Performance Warehouse in CA Chorus for DB2 Database Management:
Note: Table DDL is located in your_db2_hlq.SPFSLIB(ARCDDL). View DDL is located in
your_db2_hlq.SPFSLIB(ARCVW418).
Application Data (Thread Statistics - Detail)
Category
Table
View
Base thread information
INSIGHT.APPLICATION_DETAIL
INSIGHT.APPLICATION_DETAIL_VW
DB2 accelerator data, by
accelerator server name
INSIGHT.APPL_ACCEL_DETAIL
INSIGHT.APPL_ACCEL_DETAIL_VW
Buffer pool data, by buffer pool
INSIGHT.APPL_BP_DETAIL
INSIGHT.APPL_BP_DETAIL_VW
Distributed data, by location
INSIGHT.APPL_DDF_DETAIL
INSIGHT.APPL_DDF_DETAIL_VW
Group buffer pool data, by group INSIGHT.APPL_GBP_DETAIL
buffer pool
INSIGHT.APPL_GBP_DETAIL_VW
Package/DBRM accounting data,
by program
INSIGHT.APPL_PGM_DETAIL_VW
INSIGHT.APPL_PGM_DETAIL
Application Data (Thread Statistics - Daily Aggregates by lpar, ssid, plan, connection,
location by 1 day)
Category
Table
View
Base thread information
INSIGHT.APPLICATION_DAILY
INSIGHT.APPLICATION_DAILY_VW
DB2 accelerator data, by
accelerator server name
INSIGHT.APPL_ACCEL_DAILY
INSIGHT.APPL_ACCEL_DAILY_VW
Buffer pool data, by buffer pool
INSIGHT.APPL_BP_DAILY
INSIGHT.APPL_BP_DAILY_VW
Distributed data, by location
INSIGHT.APPL_DDF_DAILY
INSIGHT.APPL_DDF_DAILY_VW
Group buffer pool data, by group INSIGHT.APPL_GBP_DAILY
buffer pool
INSIGHT.APPL_GBP_DAILY_VW
Package/DBRM accounting data,
by program
INSIGHT.APPL_PGM_DAILY_VW
INSIGHT.APPL_PGM_DAILY
Chapter 4: Addressing Configuration Changes 41
Set Up the Performance Warehouse
Subsystem Data (Subsystem Statistics - Detail)
Category
Table
View
Base subsystem information INSIGHT.SUBSYSTEM_DETAIL
INSIGHT.SUBSYSTEM_DETAIL_VW
DB2 accelerator data, by
accelerator server name
INSIGHT.SUBSYS_ACCEL_DETAIL
INSIGHT.SUBSYS_ACCEL_DETAIL_VW
Buffer pool data, by buffer
pool
INSIGHT.SUBSYS_BP_DETAIL
INSIGHT.SUBSYS_BP_DETAIL_VW
Distributed data, by location INSIGHT.SUBSYS_DDF_DETAIL
INSIGHT.SUBSYS_DDF_DETAIL_VW
Group buffer pool data, by
group buffer pool
INSIGHT.SUBSYS_GBP_DETAIL_VW
INSIGHT.SUBSYS_GBP_DETAIL
DB2 storage use and
INSIGHT.SUBSYS_STORAGE_AS_DETAI INSIGHT.SUBSYS_STORAGE_AS_DETAIL_V
address space-related data, L
W
by address space name
DB2 storage use and other
DB2 storage use data
INSIGHT.SUBSYS_STORAGE_DETAIL
INSIGHT.SUBSYS_STORAGE_DETAIL_VW
Subsystem Data (Subsystem Statistics - Daily)
Category
Table
View
Base subsystem information
INSIGHT.SUBSYSTEM_DAILY
INSIGHT.SUBSYSTEM_DAILY_VW
DB2 accelerator data, by
accelerator server name
INSIGHT.SUBSYS_ACCEL_DAILY
INSIGHT.SUBSYS_ACCEL_DAILY_VW
Buffer pool data, by buffer pool
INSIGHT.SUBSYS_BP_DAILY
INSIGHT.SUBSYS_BP_DAILY_VW
Distributed data, by location
INSIGHT.SUBSYS_DDF_DAILY
INSIGHT.SUBSYS_DDF_DAILY_VW
Group buffer pool data, by
group buffer pool
INSIGHT.SUBSYS_GBP_DAILY
INSIGHT.SUBSYS_GBP_DAILY_VW
Subsystem Data (Parameters)
Category
Table
View
DB2 subsystem parameters
information
INSIGHT.SUBSYS_ZPARMS
INSIGHT.SUBSYS_ZPARMS_VW
System buffer pool parameters
information
INSIGHT.SUBSYS_BP_PARMS
INSIGHT.SUBSYS_BP_PARMS_VW
Group buffer pool parameters
information
INSIGHT.SUBSYS_GBP_PARMS
INSIGHT.SUBSYS_GBP_PARMS_VW
42 Site Preparation Guide
Set Up the Performance Warehouse
Chapter 4: Addressing Configuration Changes 43
Appendix A: Improving Performance
To improve performance of the integrated back-end CA Database Management
Solutions for DB2 for z/OS with CA Chorus for DB2 Database Management, create
indexes on the following DB2 catalog tables:
■
Index on SYSTABLES (DBNAME,TSNAME). Sample in
your_db2tools_hlq.CDBASRC(CATDTX08).
■
Index on SYSTABLES (TBCREATOR,TBNAME). Sample in your_db2tools_hlq.CDBASRC
(CATDTX09). This index is also the DB2 recommended index DSNDTX03.
■
Index on SYSSYNONYMS(TBNAME,TBREATOR).Sample in
your_db2tools_hlq.CDBASRC(CATDYX02)
■
Index on SYSRELS (IXNAME,IXOWNER)
■
Index on SYSPACKAGE (NAME,COLLID)
■
Index on SYSTABLESPACE (NAME)
■
Index on SYSVIEWDEP (DCREATOR, DNAME). Sample in
your_db2tools_hlq.CDBASRC(CATGGX02).
If you do not have many Views, Aliases, and so on, in a table, the cursor using TBNAME
and TBCREATOR for SYSTABLES has a low cardinality for the SYSIBM.DSNDTX03 index.
The index uses tablespace scans instead of the index access path.
To update these indexes manually, complete the following steps:
1.
Update SYSIBM.SYSINDEXES table with FIRSTKEYCARDF=200 and
FULLKEYCARDF=2000 for index DSNDTX03.
For example, UPDATE SYSIBM.SYSINDEXES SET FIRSTKEYCARDF = 200,
FULLKEYCARDF = 2000 WHERE NAME = 'DSNDTX03' AND CREATOR = 'SYSIBM';
2.
Run RUNSTATS UPDATE(NONE).
The dynamic statement cache is invalidated. A new access path is selected for index
DSNDTX03.
Note: Any time that you run RUNSTATS on the catalog, manually update the
FIRSTKEYCARDF and FULLKEYCARDF values and repeat the preceding steps.
Appendix A: Improving Performance 45
Appendix B: CA Chorus for DB2 Database
Management Installation Worksheet
Use this worksheet as a checklist for installing CA Chorus for DB2 Database
Management and to gather all required installation parameters.
CA Database Management Solutions for DB2 for z/OS Configuration Information
The following installation and configuration information is required when you install and
configure CA Chorus for DB2 Database Management:
 Record the high-level qualifier for the deployed target libraries for the following CA
Database Management Solutions for DB2 for z/OS:
■
CA Detector
■
CA Plan Analyzer
■
CA RC/Migrator
■
CA RC/Query
■
CA RC/Update
■
CA Subsystem Analyzer
■
CA SYSVIEW for DB2
■
General components: Xmanager, Xnet. Batch Processor, Object Framework
Services (OFS), and CA Chorus DBA Services (FMID EU9/CHRDBM).
This information is used in the CA Chorus installation.
■
■
Started task user ID values:
–
OFAPROC—Object Framework Services agent (OFA) for DB2 object migration in
CA Chorus for DB2 Database Management.
–
PTXMAN—Xmanager (execution manager).
–
PXNPROC and PXNPROCE—Xnet (execution manager connection).
Xnet port values for the PORT symbolic in the your_db2tools_hlq.PXNPROC JCL. This
value is specified when the DB2 subsystems are defined for CA Chorus for DB2
Database Management.
Appendix B: CA Chorus for DB2 Database Management Installation Worksheet 47
Set Up the Performance Warehouse
CA Chorus for DB2 Database Management Configuration
The following values are specified during CA Chorus for DB2 Database Management
configuration:
■
JOB statement settings—&CAI (the hlq where the CA Chorus installation data sets
are defined).
■
Confederation settings in E3KCFG10 (your_chorusdba_hlq.CE3KPARM):
–
TRACE—Activates tracing during the initial configuration processing. The
default is 0. The valid range is 0 through 7.
–
REFRESH—Sets the minimum time limit in seconds between configuration
refreshes. The default is 60. The valid range is 60 through 300.
–
GLOBALAPPLID—Specifies the application name that is associated with the
PassTicket definition in the security subsystem that is defined for use with CA
Chorus for DB2 Database Management. The default is DB2TOOLS. This value
must match the PASSNAME() specified in the Xnet startup parameters for the
target CA Database Management Solutions for DB2 for z/OS installation. The
actual SESSKEY value assigned to that application name in the security
subsystem definitions must be identical on the DSH z/OS system and on the
Xnet z/OS system. When Xnet receives a CA Chorus request containing a
PassTicket, the following processing occurs:
■
Xnet calls the security subsystem to authenticate the user access request
to the CA Database Management Solutions for DB2 for z/OS
■
Xnet validates the PassTicket that was generated for the user by the DSH.
Note: The TRACE, REFRESH, and GLOBALAPPLID default values are acceptable in
most instances.
–
CONFEDERATION1 through CONFEDERATION5—Identifies the Xnet connections
in comma-separated value (CSV) format to create a logical grouping that is
known as a confederation. Add a confederation definition as follows for each
Xnet server installation in your CA Chorus for DB2 Database Management
configuration: The confederation includes the Xnet server (conf), the TCP/IP
host address (host), and port (port) that are required to connect with the CA
Chorus server. If an APPLID is specified, this value overrides the GLOBALAPPLID
value.
Examples:
# DEFAULT Confederation member definitions
conf=default host=system1.com port=1027
conf=default host=system2.com port=1027
#
# TEST Confederation member definitions
conf=test host=system1.com port=1229 Applid=DB2TOOLS
conf=test host=system3.com port=6791 Applid=DB2TOOLS
48 Site Preparation Guide
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement