CA Software Change Manager for Mainframe Implementation Guide · CA Software Change Manager for...

Implementation Guide r12

CA Software Change Manager for Mainframe

This documentation and any related computer software help programs (hereinafter referred to as the “Documentation”) is for the end user’s informational purposes only and is subject to change or withdrawal by CA at any time.

This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA. This Documentation is confidential and proprietary information of CA and protected by the copyright laws of the United States and international treaties.

Notwithstanding the foregoing, licensed users may print a reasonable number of copies of the documentation for their own internal use, and may make one copy of the related software as reasonably required for back-up and disaster recovery purposes, provided that all CA copyright notices and legends are affixed to each reproduced copy. Only authorized employees, consultants, or agents of the user who are bound by the provisions of the license for the product are permitted to have access to such copies.

The right to print copies of the documentation and to make a copy of the related software is limited to the period during which the applicable license for the Product remains in full force and effect. Should the license terminate for any reason, it shall be the user’s responsibility to certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed.

EXCEPT AS OTHERWISE STATED IN THE APPLICABLE LICENSE AGREEMENT, 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 THE END USER OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED OF SUCH LOSS OR DAMAGE.

The use of any product referenced in the Documentation is governed by the end user’s applicable license agreement.

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.

All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

Copyright © 2007 CA. All rights reserved.

CA Product References This document references the following CA products:

CA Software Change Manager for Mainframe (CA SCM for Mainframe)

CA Software Change Manager for Mainframe Automated Configuration (CA SCM for Mainframe Automated Configuration)

CA Software Change Manager for Mainframe Extended Processors (CA SCM for Mainframe Extended Processors)

CA Software Change Manager for Mainframe Parallel Development (CA SCM for Mainframe Parallel Development)

CA Software Change Manager for Mainframe Quick Edit (CA SCM for Mainframe Quick Edit)

CA Software Change Manager for Mainframe Footprint Synchronization (CA SCM for Mainframe Footprint Synchronization)

CA Software Change Manager for Mainframe External Security Interface (CA SCM for Mainframe External Security Interface)

CA Software Change Manager for Mainframe InfoMan Interface (CA SCM for Mainframe InfoMan Interface)

CA Software Change Manager for Mainframe CA Librarian® Interface (CA SCM for Mainframe CA Librarian Interface)

CA Software Change Manager for Mainframe CA Netman™ Interface (CA SCM for Mainframe CA Netman Interface)

CA Software Change Manager for Mainframe CA Panvalet® Interface (CA SCM for Mainframe CA Panvalet Interface)

CA Software Change Manager for Mainframe CA Roscoe®Interface (CA SCM for Mainframe CA Roscoe Interface)

CA Software Change Manager for Mainframe Option for Remote DB2 for z/OS

CA ACF2 ™ for z/OS (CA ACF2 for z/OS)

CA Change Manager Enterprise Workbench (CA CM Enterprise Workbench)

CA Common Services™ (CA Common Services)

CA Endevor®/DB for CA IDMS™ (CA Endevor/DB for CA IDMS)

CA Librarian® Base for z/OS (CA Librarian Base for z/OS)

CA Netman™ (CA Netman)

CA Panvalet® for z/OS (CA Panvalet for z/OS)

CA Roscoe® Interactive Environment (CA Roscoe IE)

CA Top Secret ® for z/OS (CA Top Secret for z/OS)

Unicenter® CA-MIM™ Resource Sharing (Unicenter CA-MIM)

Contact Technical Support For online technical assistance and a complete list of locations, primary service hours, and telephone numbers, contact Technical Support at http://ca.com/support.

http://www.ca.com/supportconnect

Contents v

Contents

Chapter 1: Introduction 9 Installation and Implementation ................................................................ 9 What You Need to Know ....................................................................... 9 Audience..................................................................................... 10

Installation Tasks for the Systems Programmer ............................................. 10 Implementation Tasks for the Administrator ................................................ 11

Installation Plan .............................................................................. 12 Variable Definitions Table ................................................................. 12 Master Control File Allocations for the Sample Application ................................... 15 Installation Worksheet .................................................................... 16 Disk Space Requirements Worksheet....................................................... 18

Chapter 2: Installing CA SCM for Mainframe 29 How to Install CA SCM for Mainframe .......................................................... 29 1-How to Prepare for the Installation........................................................... 29

CA Common Services for Product Licensing and Authorization................................ 30 NDVRC1 Authorization .................................................................... 33 Activate the Changes ..................................................................... 34 Verify CA Common Services are Running ................................................... 34 How to Enable Concurrent Action Processing................................................ 35 Installation Cartridge Contents............................................................. 37

2-Unload the Install File....................................................................... 37 3-How to Edit the INSTALL Data Set ........................................................... 39

Edit and Run BC1JJB01.................................................................... 39 Edit and Run BC1JJB02.................................................................... 40 Edit and Run BC1JJB03.................................................................... 41 Copy Include Members to a JES PROCLIB Library ........................................... 46

4-Installation Considerations .................................................................. 47 Authorized Library Considerations.......................................................... 47 LINKLST/LPA Considerations............................................................... 48 How to Use LINKLIST or LPA Libraries for the AUTHLIB Data Sets ............................ 48 How to Determine LPA Load Module Storage Requirements .................................. 49

5-How to Define CA SCM for Mainframe to the ISPF Environment ................................ 50 The ISPF LIBDEF Services Method ......................................................... 51 The TSO FREE and ALLOCATE Method ...................................................... 53 The TSO Logon Procedure Method ......................................................... 54 Global Resource Sharing Considerations .................................................... 54

vi Implementation Guide

Concurrent Release Considerations......................................................... 57 ISP Command Table Considerations........................................................ 58

Chapter 3: Implementing the Sample Application 59 The Sample Application ....................................................................... 59

Sample Application Naming Conventions ................................................... 60 How to Implement the Sample Application ..................................................... 61

Defaults Table (C1DEFLTS) ................................................................ 61 1-How to Edit C1DEFLTS .................................................................. 62 2-How to Define and Allocate Your Libraries ................................................ 64 3-How to Define the Sample Application Inventory Structure (SMPLJOB3) .................... 70 4-How to Verify the Implementation ....................................................... 71 5-Perform ACM Query Facility Verification .................................................. 83

Additional Sample Jobs ....................................................................... 84

Chapter 4: Testing New Releases with Your Data 85 How to Test New Releases with Your Data...................................................... 85

Copy Your Element Catalog................................................................ 86 Copy the Master Control Files.............................................................. 86 Copy the Package File..................................................................... 86 Update Your C1DEFLTS Table.............................................................. 87 Synchronize the Element Catalog with Your MCFs ........................................... 87 Copy ACMQ Files.......................................................................... 87 Allocate Base, Delta, and Source Processor Output Libraries ................................. 88 Copy Production Data ..................................................................... 88 Identify Test Libraries to CA SCM for Mainframe ............................................ 88 Test the New Release ..................................................................... 89

Chapter 5: Implementation Considerations 91 Organizational and Technical Considerations.................................................... 91 Considerations for Organizational Change ...................................................... 92 Considerations for Developing a Strategy ...................................................... 92 Recommendations for Selecting an Implementation Team ....................................... 93 How to Introduce CA SCM for Mainframe to Your Development Team ............................ 95 Recommendations for a Pilot Project ........................................................... 98 How to Build Momentum for Your Implementation .............................................. 99

Chapter 6: Implementing CA SCM for Mainframe 101 Implementations ............................................................................ 101

Contents vii

Implementation Prerequisites............................................................. 101 Decide on the Implementation ............................................................ 102

How to Implement for Source Management ................................................... 103 1-How to Define Your Software Life Cycle ................................................. 103 2-Analyze the Inventory.................................................................. 108 3-Define and Implement the Logical Structure ............................................. 109 4-Define the Physical Structure ........................................................... 111 5-Define CCIDs (Optional)................................................................ 115 6-Enable Package Processing ............................................................. 116 7-Define Site Level Type Processing Sequence (Optional)................................... 118

How to Implement for Output Management ................................................... 119 Define and Allocate Output Libraries ...................................................... 119 Define Processors........................................................................ 121

How to Implement for Configuration Management ............................................. 123 Enable ACM ............................................................................. 123

How to Finalize the Implementation........................................................... 123 Enable Security .......................................................................... 123 Load the Inventory....................................................................... 124 Enable the ACM Baseline ................................................................. 124 Provide Internal Training ................................................................. 125 Go into Production ....................................................................... 125

Appendix A: Frequently Asked Questions 127 LMP Key Codes .............................................................................. 127 Support Issues .............................................................................. 128 New Features ............................................................................... 129 ACMROOT, ACMXREF, and the ELEMENT Catalog............................................... 129 Package Approval............................................................................ 129 The Display Elements Action ................................................................. 130 Message Severity............................................................................ 130 C1DEFLTS and the Element Catalog........................................................... 131 Change Order ............................................................................... 131 The Element Catalog and Element Registration ................................................ 132 The ENTERPRISE_PKG=A Field ............................................................... 132 Reassembling Exit Programs ................................................................. 133 API Compatibility ............................................................................ 133 The Security Table........................................................................... 133 Long Name Elements ........................................................................ 134

Appendix B: Statement of Integrity 135 CA Software Change Manager for Mainframe Statement of System Integrity..................... 135

viii Implementation Guide

Glossary 137

Index 161

Introduction 9

Chapter 1: Introduction

This section contains the following topics:

Installation and Implementation (see page 9) What You Need to Know (see page 9) Audience (see page 10) Installation Plan (see page 12)

Installation and Implementation Using the CA SCM for Mainframe installation file and this guide, you can:

Plan your installation and implementation (see page 12).

Install CA SCM for Mainframe for the first time (see page 29).

Implement the sample application (see page 59).

The sample application helps you understand how to implement CA SCM for Mainframe.

Upgrade, test, and validate a new CA SCM for Mainframe release (see page 85).

Perform this task if CA SCM for Mainframe is already installed and configured at your site.

Implement CA SCM for Mainframe at your site (see page 101).

What You Need to Know To install and implement CA SCM for Mainframe, you should be familiar with, and your site must meet, the following requirements:

You need a working knowledge of the mainframe environment, the z/OS mainframe operating system, the Time Sharing Option facility (TSO), and the Interactive System Productivity Facility (ISPF).

You need a working knowledge of OS JCL, the standard IBM utilities, and how to use the ISPF/PDF editor.

You must know how to administer VSAM catalog structures.

You must have the proper security authority to define data sets and perform system authorization functions.

Audience

10 Implementation Guide

You have a working knowledge of, and can execute, the IBM SMP/E utility program.

Your site uses 3390-type disk devices.

Important! All SPACE parameters are based on 3390 devices. If your site uses another type of device, you must adjust them accordingly.

The TSO profile prefix is set to the user ID or to NOPREFIX.

Audience This guide addresses the tasks of installing CA SCM for Mainframe and implementing the sample application, if you are a first time user, or testing the new release with your data, if you are not installing CA SCM for Mainframe for the first time. Additional implementation tasks are discussed in the Administration Guide. At many sites, the installation is performed by the systems programmer and the implementation is performed by the CA SCM for Mainframe administrator.

Installation Tasks for the Systems Programmer

The systems programmer usually completes the following steps in the installation process:

1. Review the Readme provided on http://ca.com/supportconnect. (The Readme is also provided in the README member in the myiprfx.myiqual.INSTALL library.)

2. Install and customize the CA Common Services components CA LMP, CAIRIM,and CAIENF for product licensing and authorization (see page 29).

3. (Optional) If you plan to use the Concurrent Action Processing feature, install and customize the CA Common Communications Interface (CAICCI).

4. Unload the INSTALL file (see page 37).

5. Edit BC1JJB01 (see page 39), BC1JJB02 (see page 40) and BC1JJB03 (see page 41) and change the variables. If necessary, you can also change the SMP/E definitions in BC1JJB01.

6. Submit job BC1JJB01 to define the SMP/E environment (see page 39).

7. Submit job BC1JJB02 to receive, apply, and accept the new release (see page 40).

8. Submit job BC1JJB03 to tailor delivered elements for your site (see page 41).

Audience

Introduction 11

9. Authorize the AUTHLIB or move the content to an existing authorized library (see page 47).

Note: Existing installations that need to run their current release and the new release on the same system/LPAR need to ensure the libraries for the new release cannot be used by accident.

10. Create a CA SCM for Mainframe environment for the new release under TSO (see page 50).

11. Define CA SCM for Mainframe to GRS (if not already completed) (see page 54).

12. Modify the TSO Command Limiting Facility to allow ISPTLIB commands (ACMQ, BC1PACMI, ESORT, EONLY, EM, QM, and so on) (see page 57). CA ACF2 for z/OS users only.

Implementation Tasks for the Administrator

The CA SCM for Mainframe administrator usually performs the following steps in the installation process:

1. Implement a Test Environment.

To complete this step, do the following:

a. Read the frequently asked questions (see page 127).

b. Read the information about how to test new releases with your data (see page 85).

c. Review the Readme provided on http://ca.com/supportconnect. (The Readme is also provided in the README member in the myiprfx.myiqual.INSTALL library.)

d. (Optional) Implement the sample application (see page 61).

2. Migrate the Existing Environment.

Complete these steps to migrate your existing environment:

a. Review the customization tables.

Note: For more information, see Customization Tables in the Administration Guide.

b. (Optional) Apply other needed optional PTFs.

c. Recompile any exits programs.

d. Perform foreground validation of user table modifications (C1DEFLTS, ENDICNFG, ENCOPTBL, SYMBOL TABLE) as follows:

1. Allocate file EN$TROPT under TSO using this command: TSO ALLOC FI (EN$TROPT) SYSOUT REUSE.

2. Start CA SCM for Mainframe in foreground.

Installation Plan


3. Split the screen and review the file under your TSU session in the SDSF DA queue.

4. Confirm that all selected options and table settings are correct.

e. Perform batch validation of user table modifications (C1DEFLTS, ENDICNFG, ENCOPTBL, SYMBOL TABLE).

– Submit a batch SCL job with the following additional DD statement: //EN$TROPT DD SYSOUT=*

– After the job completes, view the output in SDSF and perform the same foreground validation as listed in the previous step.

Installation Plan To ensure that you successfully install and configure CA SCM for Mainframe, organize and plan your installation carefully. Use the following tables and worksheets to review and record the information and values you need to use in the installation, and to record the estimated disk space requirements for your site.

Variable Definitions Table (see page 12)

Review the detailed definitions for several variables in the different installation JCL jobs.

Installation Worksheet (see page 16)

Record the information and values you need to install at your site.

Master Control File Allocations for the Sample Application (see page 15)

Provides allocation information for the CA SCM for Mainframe sample application.

Disk Space Requirements Worksheet (see page 18)

Estimate the disk space requirements for your site.

Variable Definitions Table

To help you organize and plan for the installation of CA SCM for Mainframe, use the following table to review and note the detailed definitions for several of the variables that are included in the different installation JCL jobs. The definitions are grouped by type, for example, qualifiers or cluster parameters. Have this table available for reference when you install CA SCM for Mainframe.

Note: For more information about the definitions for the parameters in the Defaults Table (C1DEFLTS), see the Administration Guide.

Installation Plan

Introduction 13

Variable Definition Type

Variable Description

Qualifiers myiprfx Highest-level qualifier used when assigning data set names for installation and execution libraries. This prefix is used for data sets that store CA SCM for Mainframe software. The software release number should be coded as part of iprfx or iqual.

Note: The total length of MYIPRFX and MYIQUAL must not exceed 16 characters.

myiqual Second-level qualifier used when assigning data sets for installation and execution libraries. This prefix is used for data sets that store CA SCM for Mainframe software. The software release number should be coded as part of iqual or iprfx.

Note: The total length of MYIPRFX and MYIQUAL must not exceed 16 characters.

myuprfx Highest-level qualifier used when assigning data set names for CA SCM for Mainframe user files. This prefix is used for data sets that store user modules. The software release number should not be coded as part of the prefix, because these data sets are independent of the release.

Note: The total length of MYUPRFX and MYUQUAL must not exceed 16 characters.

myuqual Second-level qualifier used when assigning data set names to CA SCM for Mainframe user files. This prefix is used for data sets that store user modules. The software release number should not be coded as part of the prefix, because these data sets are independent of the release.

Note: The total length of MYUPRFX and MYUQUAL must not exceed 16 characters.

Sample Application Variables

SYSCLECOMP The COBOL/LE compiler load library.

SYSCLERUN The COBOL/LE runtime library.

SYSCLELKED The COBOL/LE Automatic Call (link) library.

SYSCIICOMP The COBOL II compiler load library.

Installation Plan




SYSCIILIB The COBOL II Automatic Call (link) library.

MONITOR=COMPONENTS Indicates whether your site uses the ACM Query Facility.

If your site received an LMP key for product AY, Automated Configuration Option (ACM), do not change anything.

If your site did not receive an LMP key, change this value to MONITOR=NONE.

ADPROC? Indicates whether your site uses processors.

If your site received an LMP key for product A9, Extended Processors, change this value to ADPROC.

If your site did not receive an LMP key, change this value to ADNOPROC.

SYSMACLIB The data set name of the system assembler macro library. For example, SYS1.MACLIB.

C?? CII or CLE. Indicates the version of COBOL in use at your site.

If you are using COBOL/LE, change this value to CLE.

If you are using COBOL II, change this value to CII.

If your site uses both COBOL/LE and COBOL II, change the value to the version of COBOL you use most often.

C??NBL CIINBL or CLENBL. Indicates the default processor group for COBOL elements delivered with the sample application. The C?? portion of this variable should be set to the same value as the variable C??.

Symbolic Device Assignment

mycart Symbolic device name for cartridge data sets.

mypdisk Symbolic device label for permanent disk data sets.

mytdisk Symbolic device label for temporary disk data sets.

Installation Plan

Introduction 15



Volume Serial Numbers mysvolser Volume serial number used by SMP/E for DD SMPTLIB.

mytvolser Volume serial number of the CA SCM for Mainframe installation cartridge.

myvvolser The volume serial number of the disk used to store VSAM clusters.

Note: For more information about volumes, see the definition of VOLUMES under Master Control File (MCF) Cluster Parameters.

mydvolser The volume serial number of the disk used to store permanent data sets.

Master Control File Cluster Parameters

For assistance, contact Technical Support at http://ca.com/support.

CYLINDERS (n n) Primary and secondary space allocations, respectively. The default value is (5 1) for Stage 1 and (5 1) for Stage 2, which is sufficient for a system with up to 750 elements in each stage.

Note: For more information about how to calculate additional space, see Disk Space Requirements Worksheet (see page 18).

Package Data Set Cluster Parameters


CYLINDERS (n n) Primary and secondary space allocations, respectively. The default value is (8 2), which is sufficient for 50 packages averaging 50 elements, with BACKOUT enabled and averaging 4 outputs per element.

Note: For more information about how to calculate additional space, see Disk Space Requirements Worksheet (see page 18).

Master Control File Allocations for the Sample Application

SMPLJOB4 allocates the following VSAM structures.

Stage Library Data Set Name

1 VSAM cluster iprfx.iqual.SMPLTEST.MCF

Cluster data component iprfx.iqual.SMPLTEST.MCF.DATA

Cluster index component iprfx.iqual.SMPLTEST.MCF.INDEX



Installation Plan


Stage Library Data Set Name

2 VSAM cluster iprfx.iqual.SMPLQA.MCF

Cluster data component iprfx.iqual.SMPLQA.MCF.DATA

Cluster index component iprfx.iqual.SMPLQA.MCF.INDEX

3 VSAM cluster iprfx.iqual.SMPLEMER.MCF

Cluster data component iprfx.iqual.SMPLEMER.MCF.DATA

Cluster index component iprfx.iqual.SMPLEMER.MCF.INDEX

4 VSAM cluster iprfx.iqual.SMPLPROD.MCF

Cluster data component iprfx.iqual.SMPLPROD.MCF.DATA

Cluster index component iprfx.iqual.SMPLPROD.MCF.INDEX

Installation Worksheet

To help you organize and plan the installation of CA SCM for Mainframe, you can use the following worksheet to record the information and values you will use to install CA SCM for Mainframe at your site.

Note: If you need clarification about variables when completing this worksheet, see the Variable Definition Table (see page 12).


Variable Your Site's Value

Qualifiers myiprfx

myiqual

myuprfx

myuqual

Sample Application Variables

SYSCLECOMP

SYSCLERUN

SYSCLELKED

SYSCIICOMP

SYSCIILIB

MONITOR=COMPONENTS

ADPROC?

Installation Plan

Introduction 17



SYSMACLIB

C??

C??NBL

Symbolic Device Assignment

mycart

mypdisk

mytdisk

Volume Serial Numbers mysvolser

mytvolser

myvvolser

mydvolser

Master Control File Cluster Parameters


CYLINDERS (n n)

FREESPACE Note: Do not change the default value of (30 30) for this parameter.

RECORDSIZE Note: Do not change the default value of (640 1200) for this parameter.

KEYS Note: Do not change the default value of (28 0) for this parameter.

SHR Note: Do not change the default value of (3 3) for this parameter.

Package Data Set Cluster Parameters


CYLINDERS (n n)

FREESPACE Note: Do not change the default value of (30 30) for this parameter.



Installation Plan




RECORDSIZE Note: Do not change the default value of (640 3070) for this parameter.

KEYS Note: Do not change the default value of (64 8) for this parameter.

SHR Note: Do not change the default value of (3 3) for this parameter.

Disk Space Requirements Worksheet

The default disk space allocations provided in the installation JCL are large enough to accommodate a pilot project (approximately 500 elements). The information may vary depending on factors such as the average number of lines per code per element, blocking factors, and disk device types. Use the information and examples in the Disk Space Requirements Worksheet to help you determine the requirements for your site. Have this worksheet available for reference when you install CA SCM for Mainframe. The worksheet is organized as follows:

Data set name and description

Default values, where appropriate

Space for your specification

Before completing the Disk Space Requirements Worksheet, consider the following information:

It is assumed that your site uses 3390-type disk devices. All SPACE parameters are based on 3390 devices. If your site uses another type of device, you must adjust them accordingly.

All libraries can be defined as operating system partitioned data sets (PDS), or, with the exception of a load library, as CA Panvalet data sets, CA Librarian data sets, or ELIB data sets. If you are defining CA Panvalet or CA Librarian data sets, be sure to allocate storage equivalent to the storage defined in the worksheet.

Note: For more information about estimating disk space allocation for ELIB, see the Utilities Guide.

When allocating a partitioned data set, be aware that for efficiency, directory blocks are allocated in increments of 45 (which is the number that can fit on a single track of a 3390-type device). In addition, in each library, one directory block exists for every four elements.

Installation Plan

Introduction 19

CA SCM for Mainframe compresses blank spaces from the base, delta, and processor listing libraries (assuming the base and delta libraries are OS/PDS or ELIB files).

Routine maintenance is required on the libraries described. For more information, see the Utilities Guide.

The number of members stored in a single partitioned data set should not exceed 5,000. Exceeding this number may result in contention problems such as severe disk contention, heavy updating, and excessive wait time for rewriting partitioned data set directories. Up-front planning in this area helps avoid problems. Keep in mind that base and delta libraries can be defined by element types.

Elements can be stored in reverse delta or forward delta format. The Disk Space Requirements Worksheet provides information for both formats in the descriptions of the base library and the delta library. The CA SCM for Mainframe sample application uses reverse delta format for storing elements.

Element Catalog Planning

Allocate one 3390 cylinder for every 600 elements in PROD. For the element index, allocate one cylinder 3390 for every 2,000 elements in PROD.

Base Library Planning

Consider the following values when planning a base library:

Data Set Name

uprfx.uqual.BASE

Description

This library contains element source as initially defined to CA SCM for Mainframe. The space requirements are a function of the number of elements (members) to be stored, the number of source lines per element, and the library manager in use. For existing PDS members to be loaded into the base library, use ISPF/PDF option 3.2 (UTILITIES, then DATASETS) to estimate the space required. To calculate the total amount of space needed, multiply the estimated space by an expansion factor (such as 1.2) that is appropriate to the expected library expansion beyond these members.

Format

PDS: DCB=(RECFM=VB,LRECL=259,BLKSIZE=0) (Forward Delta)

PDS: DCB=(RECFM=FB,LRECL=80,BLKSIZE=0) (Reverse Delta)

Installation Plan


Space Calculation

To estimate the number of PDS directory blocks needed, assume one directory block exists for every four elements. For efficiency, directory blocks should be allocated in increments of 45 for a 3390-type device (or whatever number can fit on a single track for another type of device). To calculate the number of directory blocks, divide the estimated number of elements (members) to be stored in the library by four. Round that result to an even multiple of 45 (for a 3390-type device). The number should be the same for base and delta libraries.

For example, assume two existing PDS libraries are placed under the control of CA SCM for Mainframe, and the total space currently occupied by members in the library takes up 100 cylinders. You can allocate a base library of 120 cylinders (100 x 1.2 = 120) to leave 20 percent free space to allow for expansion.

Forward Delta Format

The following values apply if you are storing elements in forward delta format.

PDS Defaults Your Site's Specification

Primary (CYL) 80

Secondary (CYL) 10

Dir Blk 180

Reverse Delta Format

The following values apply if you are storing elements in reverse delta format.


Primary (CYL) 90

Secondary (CYL) 15

Dir Blk 90

Installation Plan

Introduction 21

Delta Library Planning

Consider the following values when planning a delta library:

Data Set Name

uprfx.uqual.DELTA

Description

This library contains change levels for elements defined to CA SCM for Mainframe. The space requirements for the library are a function of the number of elements to be stored, the volatility of the elements (that is, the number of changes that are expected and the extent of those changes), and the library manager in use. A good starting point is a size that is half as large as the base library. The number of directory blocks should be the same as for the base library.

Note: If the Automated Configuration Manager is installed at your site, increase the file size by 33 percent and triple the number of directory blocks. In addition, you cannot use the same library as the Base and Delta library.

Format

PDS: DCB=(RECFM=VB,LRECL=28332,BLKSIZE=0) (Same Format for Forward and Reverse Delta)

Forward Delta Format

The following values apply if you are storing elements in forward delta format.


Primary (CYL) 40

Secondary (CYL) 10

Dir Blk 180


The following values apply if you are storing elements in reverse delta format.


Primary (CYL) 40

Secondary (CYL) 15

Dir Blk 270

Installation Plan


Package Data Set Planning

Consider the following values when planning a package data set:

Data Set Name

uprfx.uqual.PACKAGE

Description

This data set stores all packages for the entire site. The size of this file is determined by the number of packages to be stored at any given time and the average size of each. The size can be difficult to calculate because packages vary greatly in size, based on number of actions and whether BACKOUT/BACKIN is enabled. The maximum size of a package record is 3070 bytes.

Defaults Your Site's Specification

Primary (CYL) 8

Secondary (CYL) 2

Format

VSAM

Processor Load Library Planning (Stage 1)

Consider the following values when planning a processor load library for Stage 1:

Data Set Name

uprfx.uqual.PRC1LOAD

Description

This library contains Stage 1 processor load modules. The GPPROCSS processor writes to this library, for elements defined with the element type PROCESS.

The size of this library is a function of the number of processors added to the system with which the library is associated and the number of lines in each processor. Estimate the total number of generate, move, and delete processors to be stored for Stage 1. Allow 1.5 tracks for each processor. For example, for a library targeted to store 15 processors, use a primary allocation of 10 tracks and a secondary allocation of 1 track.

Installation Plan

Introduction 23

To determine the number of directory blocks needed, assume one directory block exists for every four processors. Then, use the previous information in Base Library to continue.


Primary (CYL) 10

Secondary (CYL) 5

Dir Blk 45

Format

DCB=(RECFM=U,LRECL=0,BLKSIZE=32760)

Listing Libraries Planning (Stage 1)

Consider the following values when planning listing libraries for Stage 1:

Data Set Names

uprfx.uqual.LISTING1

uprfx.uqual.PRC1LIST

Description

These libraries contain listings that correspond to either a Stage 1 user-defined listing library (uprfx.uqual.LISTING1) or the Stage 1 processor load modules (uprfx.uqual.PRC1LIST).

Size information for each library is discussed in the following section. To determine the number of directory blocks needed for either library, assume one directory block exists for every four listings. Then, use the previous information in Base Library to continue.

Format

PDS: DCB=(RECFM=VBA,LRECL=28332,BLKSIZE=0)

User Listing Library

The CONLIST utility writes to the user listing library, for those elements defined with a type associated with a processor containing this utility. To estimate the size of the user listing library, allocate one track per member. However, the item being stored can greatly influence the overall size of the library. For example, a one-page printout takes up much less space than a 600-page compile.

A good estimate for compile listings is two tracks per member. With a user library targeted to store 100 compile listings, for example, use a primary allocation of 200 tracks and a secondary allocation of 10 tracks.

Installation Plan


Processor List Library

The GPPROCSS processor writes to the processor list library, for those elements defined with the type PROCESS. The size of the processor list library is a function of the number of processors added to the system with which the library is associated, and the number of lines in each processor.

Estimate the total number of generate, move, and delete processors to be stored for Stage 1. Allow one track for each processor. For example, for a library targeted to store 15 processors, use a primary allocation of 15 tracks and a secondary allocation of five tracks.

The following table contains the defaults.

PDS Defaults (PRC1LIST)

PDS Defaults (LISTING1)

Your Site's Specification (PRC1LIST)

Your Site's Specification (LISTING1)

Primary (CYL) 10 200

Secondary (CYL) 5 10

Dir Blk 45 45

Data Set (MCF) Planning (Stage 1)

Consider the following values when planning a data set for Stage 1:

Data Set Name

uprfx.uqual.STAGE1

Description

This data set contains the Stage 1 Master Control File entries. The size of this file is based on the number of systems, subsystems, elements, types, and processor groups to be stored at Stage 1.


Primary (CYL) 5

Secondary (CYL) 1

Format

VSAM

Installation Plan

Introduction 25

COPYLIB Planning (Stage 1)

Consider the following values when planning a COPYLIB for Stage 1:

Data Set Name

uprfx.uqual.COPYLIB1

Description

This library contains the latest full source of each element created during output management at Stage 1. The size of this library is a function of the exact amount of space the members consume outside of CA SCM for Mainframe.

For existing partitioned data set members, use the ISPF/PDF option 3.2 (UTILITIES, then DATASETS) to estimate the space required. Multiply the space required by an expansion factor (such as 1.2) that is appropriate to the expected library growth beyond these members.

To determine the number of directory blocks needed, assume one directory block exists for every four members. Then, use the previous information in Base Library to continue.

Note: If you are using forward deltas, a source output library must be defined. In addition, if you are using reverse deltas, defining a source output library is optional. The base image library performs the same function as the source output library.

Your Site's Specification

Primary (CYL)

Secondary (CYL)

Format

DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)

Installation Plan


Processor Load Library Planning (Stage 2)

Consider the following values when planning a processor load library for Stage 2:

Data Set Name

uprfx.uqual.PRC2LOAD

Description

This library contains Stage 2 processor load modules. Determine the size and number of directory blocks for this file as you would for the Stage 1 library, uprfx.uqual.PRC1LOAD. For more information, see Processor Load Library (Stage 1).


Primary (CYL) 10

Secondary (CYL) 5

Dir Blk 45

Format

DCB=(RECFM=U,LRECL=0,BLKSIZE=32760)

Listing Libraries Planning (Stage 2)

Consider the following values when planning listing libraries for Stage 2:

Data Set Names

uprfx.uqual.LISTING2

uprfx.uqual.PRC2LIST

Description

These libraries contain listings that correspond to a Stage 2 user-defined listing library (uprfx.uqual.LISTING2) or the Stage 2 processor load modules (uprfx.uqual.PRC2LIST).

Determine the size and number of directory blocks for this file as you would for the Stage 1 libraries, uprfx.uqual.LISTING1 and uprfx.uqual.PRC1LIST. For more information, see Listing Libraries (Stage 1).





Primary (CYL) 10 200

Installation Plan

Introduction 27





Secondary (CYL) 5 10

Dir Blk 45 45

Format

PDS: DCB=(RECFM=VBA,LRECL=28332,BLKSIZE=0)

Data Set (MCF) Planning (Stage 2)

Consider the following values when planning a data set for Stage 2:

Data Set Name

uprfx.uqual.STAGE2

Description

This data set contains the Stage 2 Master Control File entries. Determine the size of this file as you would for the Stage 1 data set, uprfx.uqual.STAGE1. For more information, see Stage 1 Data Set (MCF).

The following table contains the defaults:

Defaults Your Site's Specification

Primary (CYL) 5

Secondary (CYL) 1

Format

VSAM

Installation Plan


COPYLIB Planning (Stage 2)

Consider the following values when planning a COPYLIB for Stage 2:

Data Set Name

uprfx.uqual.COPYLIB2

Description

This library contains the latest full source of each element created during output management at Stage 2. Determine the size of this library as you would for the Stage 1 library, uprfx.uqual.COPYLIB1. For more information, see COPYLIB (Stage 1).

Note: If you are using forward deltas, a source output library must be defined. In addition, if you are using reverse deltas that are not encrypted, defining a source output library is optional. The base image library performs the same function as the source output library.

Your Site's Specification

Primary (CYL)

Secondary (CYL)

Format

DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)

Installing CA SCM for Mainframe 29

Chapter 2: Installing CA SCM for Mainframe


How to Install CA SCM for Mainframe (see page 29) 1-How to Prepare for the Installation (see page 29) 2-Unload the Install File (see page 37) 3-How to Edit the INSTALL Data Set (see page 39) 4-Installation Considerations (see page 47) 5-How to Define CA SCM for Mainframe to the ISPF Environment (see page 50)

How to Install CA SCM for Mainframe Perform the following basic steps to install CA SCM for Mainframe:

1. Prepare for CA SCM for Mainframe (see page 29).

2. Unload the install file. (see page 39)

3. Edit the install data set.

4. Review the installation considerations (see page 47).

5. Define CA SCM for Mainframe to the ISPF environment (see page 50).

Note: In some of these steps, you must define specific JCL variables for your site. For more information, see Installation Plan (see page 12).

After you have installed CA SCM for Mainframe, you are ready to implement the product at your site. If you are installing CA SCM for Mainframe for the first time, you should use the sample application. If you are an existing client, you can either use the sample application, or test with your existing data.

1-How to Prepare for the Installation To prepare for the base installation of CA SCM for Mainframe, do the following:

1. Understand CA Common Services for product licensing and authorization (see page 30).

2. Identify the CA SCM for Mainframe load module name NDVRC1 to the authorized TSO program, command, and service facility list (see page 33).

1-How to Prepare for the Installation


3. Understand the space requirements for the base CA SCM for Mainframe libraries.

4. Activate the changes (see page 34).

CA Common Services for Product Licensing and Authorization

CA SCM for Mainframe uses CA Common Services for product licensing and authorization. CA Common Services is a group of system services that protect your investment in software products by helping to manage your data center more efficiently.

The CA Common Services components used by CA SCM for Mainframe include the following: CAIRIM, CA LMP, and CAIENF. These services help you run CA SCM for Mainframe.

CAIRIM

CA SCM for Mainframe uses the CA Common Services Resource Initialization Manager (CAIRIM) component for product license authorization. CAIRIM routines are grouped under CA z/OS Dynamic Service Code S910.

Important! CAIRIM is mandatory for CA SCM for Mainframe. It must be installed and started with CA SCM for Mainframe within 30 minutes of IPL time. CAIRIM is part of CA Common Services for z/OS. For more information about the features and associated utilities of CAIRIM, see the CA Common Services for z/OS Getting Started.

CA LMP

CA SCM for Mainframe requires the proper level of the CA License Maintenance Program (LMP) to initialize correctly. CA LMP, which provides a standardized, automated approach to the tracking of licensed software, is provided as an integral part of CAIRIM. Authorization codes you may have previously specified in the C1DEFLTS table are no longer processed.

The CA License Management Program uses common real-time enforcement software to validate the user's configuration. CA LMP reports on license, usage, and financial activities of CA SCM for Mainframe. The routines that accomplish this are integrated into the CA z/OS dynamic service code S910 (the CAIRIM service).

Some of the features of CA LMP include:

Common key data set can be shared among many CPUs.

Check digits are used to detect errors in transcribing key information.



Execution keys can be entered without affecting any CA software solution already running.

No special maintenance requirements exist.

Note: For more information about defining the CA LMP execution key to the CAIRIM parameters, see the CA Common Services for z/OS Getting Started.

The LMP Key Certificate

Examine the CA LMP Key Certificate you received with your CA SCM for Mainframe installation or maintenance cartridge. Your certificate contains the following information.

Product Name

The trademarked or registered name of CA SCM for Mainframe as licensed for the designated site and CPUs.

Product Code

A two-character code that corresponds to one or more CA SCM for Mainframe features.

Supplement

The reference number of your license for the particular CA SCM for Mainframe feature, if applicable.

CPU ID

The code that identifies the specific CPU for which the installation of CA SCM for Mainframe is valid.

Execution Key

An encrypted code required by CA LMP for product initialization. Also referred to as the LMP CODE.

Expiration Date

The date your license for CA SCM for Mainframe expires in the format ddmmmyy.

Contact Technical

The name of the designated technical contact at your site, who is responsible for installation and maintenance of CA SCM for Mainframe. This is the person to whom CA addresses all CA LMP correspondence.



MIS Director

The name of the Director of MIS, or the person who performs this function at your site. If the title, but not an individual's name, is indicated on the certificate, you should supply the actual name when correcting and verifying the certificate.

CPU Location

The address of the building in which the CPU is installed.

LMP Execution Keys

You must add the CA LMP Execution Keys provided on the Key Certificate to the CAIRIM parameters to ensure proper initialization of CA SCM for Mainframe. To define a CA LMP Execution Key, modify member KEYS in CALPPOPTION.

The following information shows the syntax for statements in the KEYS member and describes the individual parameters:

PROD(pp) DATE(ddmmmyy) CPU(tttt-mmmm/ssssss) LMPCODE(kkkkkkkkkkkkkkkk)

pp

The two-character product code. This required code matches the product code already in use by CAIRIM for any earlier versions of CA SCM for Mainframe, if applicable.

ddmmmyy

The licensing agreement expiration date.

tttt-mmmm

The CPU type and model on which the product is to run. If the CPU type or model requires less than four characters, use blanks for the unused characters. This is a required parameter.

ssssss

The serial number on which the product is to execute. This is a required parameter.



kkkkkkkkkkkkkkkk

The Execution Key required to run the product. This key is provided on the Key Certificate shipped with each CA software solution.

The following is an example LMP KEYS entry. The product code and execution key values will differ in your installation. Note the trailing blank in the CPU model number.

PROD(ZZ) DATE(08DEC99) CPU(3090-600 /370623) LMPCODE(0408A0423C0123EF)

Note: For more information about defining the CA LMP Execution Key to CAIRIM, see the CA Common Services for z/OS Getting Started.

Verification of the LMP Execution Keys Installation

Before enabling the test environment, ensure that all necessary CA Common Services LMP Execution Keys have been installed as described in the CA Common Services for z/OS Getting Started. You can use the same execution key being used for your production environment; a new key is not required when upgrading to a newer release of the product.

Some users may not be licensed for all features of the product. The demonstration job stream that is part of this phase uses facilities from all features of CA SCM for Mainframe.

Ensure that a valid CA LMP Execution Key, supplied by CA, has been specified to the CA Common Services CAIRIM licensing component.

Note: If you do not have a full feature execution key, you can obtain a temporary one by contacting the CA LMP support group at http://ca.com/support.

NDVRC1 Authorization

Identify the CA SCM for Mainframe load module name NDVRC1 to the authorized TSO program, command, and service facility list. This process varies depending on the TSO environment in which you are operating. If you have performed this procedure for a previous release of CA SCM for Mainframe, you do not need to repeat it.

To authorize NDVRC1, add the load module name NDVRC1 to the AUTHPGM, AUTHCMD, and AUTHTSF sections of member IKJTSO00, in SYS1.PARMLIB.

Note: For more information about NDVRC1 authorization, see the IBM TSO/E documentation.




Activate the Changes

When you have added NDVRC1 to the appropriate lists and made the necessary changes to LNKLSTnn and IEAAPFnn, you can use the PARMLIB and SETPROG commands to dynamically activate the changes or re-IPL the system.

Verify CA Common Services are Running

The CA Common Services components CAIRIM and CAIENF must be installed and running on your mainframe. CAICCI is required only if you want to use the Concurrent Action Processing feature. If they are not already installed and running, you must install these services according to the instructions in the CA Common Services for z/OS Getting Started. After installation is complete, you can proceed.

To determine whether CAIENF and CAICCI are installed and running

1. Go to the SDSF status display and enter the prefix ENF*.

Note: If you do not see ENF* active on your system, contact your systems programmer to start it.

2. If the job is running, select it and search for (Find) CAICCI within the job.

If you find CAICCI: CAIENF and CAICCI are running.

If you do not find CAICCI: Check your site’s CAI.CAIPROC library to see if the ENF member has been modified to run CAICCI at your site.

– If the ENF member exists: Complete the tasks in Customize the ENF Procedure for CAICCI and then have the member started.

– If the ENF member does not exist: Contact your local systems support person to determine the status of CAIRIM, CAIENF, and CAICCI on your system and to help you complete the tasks in the next section.



How to Enable Concurrent Action Processing

The ENF procedure for CAICCI services enables the Concurrent Action Processing feature. Because Concurrent Action Processing uses the CAICCI SPAWN facility, you must append a Concurrent Action Processing spawn parameter file definition to the SPNPARMS DD in the ENF procedure. You can find the ENF procedure in the initial CAI.CAIPROC library. However, your system administrator may have copied the procedure to the system PROCLIB.

To enable Concurrent Action Processing, do the following:

1. Append a Concurrent Action Processing spawn parameter file definition named SPNPARMS DD to the ENF procedure.

//SPNPARMS DD DISP=SHR,DSN=&OPTLIB(&SPNPAR1)

// DD DISP=SHR,DSN=&OPTLIB(&SPNPARn)

SPNPARn

A symbolic for a CAIENF parameter member, where n is replaced by the next available sequential number in the list of parameter files.

2. Customize the SPNPARn parameters by editing the CAICCI SERVICE and PROCESS statements in the in the SPNPARn file.

SERVICE statement

Identifies the host application

PROCESS statement

Identifies the JCL procedure that executes Endevor

ENDEVOR

Specifies the name of the procedure associated with the CA SCM for Mainframe host application to be started by the CAICCI SPAWN service during Concurrent Action Processing. The ENDEVOR value is the name of the started task procedure that is initiated by a SPAWN request. An example of a SPNPARn file is shown at the end of this procedure.

Note: It is important to keep the statements in the exact format provided, maintaining spaces and column alignments. For complete information on defining and using CAICCI statements, see the CA Common Services documentation.



3. Customize the ENDEVOR Procedure. A sample of the JCL for the ENDEVOR procedure is located in the JCLLIB JCL included with CA SCM for Mainframe.

a. After modification, copy it into a specific client PROCLIB. ENDEVOR is initiated as a started task.

b. If you change the ENDEVOR member name, be sure to update the PROCNAME value in the CCI PROCESS statement of the SPNPARn file to reflect the new procedure name.

4. Make sure that a default Region ACID is defined, if required for your site's security system. Because ENDEVOR is initiated as a started task (STC), it is likely that a default Region ACID must be defined for ENDEVOR to your security system. Consult your security administrator for more information.

5. If this is your initial install of these CAICCI components, you do not need to IPL your system after installation. If this is a subsequent install, see the CA Common Services for z/OS documentation for more information.

6. (Optional) If you want to use Workload Management to control the resources used by the spawned STCs, we recommend the following definitions.

a. For the Action Request Regions—The action request regions are the started tasks that are created to service requests concurrently. The started task procedure name is defined in the PROCNAME= parameter of the CCI PROCESS statement.

Define the started tasks in a Service class that is below 1st Period TSO, and above the 1st Period of Regular Development Batch. This is an Importance of 2 or 3, depending on the definition of the 2 Service classes.

b. For the Routing Region—The routing region is the batch job or CA CM Enterprise Workbench started task that has requested that actions be processed concurrently. These jobs can be in Service class SYSSTC, or a high-priority Service class such as STCHI. (Typically, STCHI is defined as Importance 2 with a Velocity of 60.)

Note: For sample CCI definitions for Concurrent Action Processing, see the member CAPCCI supplied in the installation SOURCE library iprfx.iqual.SOURCE.

2-Unload the Install File


Installation Cartridge Contents

The CA SCM for Mainframe installation cartridge contains the files shown in the table.

Important! The files in the table are for r12. The files change for service packs. If you are installing a service pack, see the Readme for the file names.

File Name Standard Label

Description

CAI.SAMPJCL 1 Main installation file

CAI.PTFLIB 17 SMP/E PTF file

CAI.SMPMCS 32 SMP/E MCS file

CHMC000.F1 33 SMP/E release file containing linked object

CHMC000.F2 34 SMP/E release file containing source members

CHMC000.F3 35 SMP/E release file containing panels

CHMC000.F4 36 SMP/E release file containing JCL

CHMC000.F5 37 SMP/E release file containing CLISTS

CHMC000.F6 38 SMP/E release file containing skeletons

CHMC000.F7 39 SMP/E release file containing samples

CHMC000.F8 40 SMP/E release file containing tables

CHMC000.F9 41 SMP/E release file containing authorized load modules

CHMC000.F10 42 SMP/E release file containing load modules

CHNC7000.F1 43 SMP/E release file for CA Roscoe IE

2-Unload the Install File The second step in the installation process is to unload the install file.

To unload the install file

1. Unload the installation file, CAI.SAMPJCL, from the installation cartridge using JCL similar to the following sample.

This JCL allocates and loads a partitioned data set containing the JCL job streams and associated control statements that, in turn, allocate and then load the CA SCM for Mainframe data sets.

2-Unload the Install File


The following data set is used to complete this task:

//YOUR JOBCARD

//****************************************************************

//* UNLOAD INSTALL FILE FOR CA SCM FOR MAINFRAME

//* RELEASE 12.0

//*

//****************************************************************

//STEP1 EXEC PGM=IEBCOPY,REGION=2048K

//SYSPRINT DD SYSOUT=*

//INDD DD DSN=CAI.SAMPJCL,

// UNIT=MYCART,

// VOL=SER=MYTVOLSER,

// LABEL=(1,SL),

// DISP=OLD

//OUTDD DD DSN=MYIPRFX.MYIQUAL.INSTALL,

// UNIT=SYSDA,

// SPACE=(TRK,(10,2,45)),

// DISP=(NEW,CATLG,DELETE),

// DCB=(RECFM=FB,LRECL=80)

//SYSIN DD *

UNLOAD COPY INDD=INDD,OUTDD=OUTDD

/*

Note: You can type this JCL manually or copy it from existing JCL.

2. Edit the following JCL variables to meet the requirements of your site:

myiprfx

Highest-level qualifier used when assigning data set names for the installation and execution libraries.

myiqual

Second-level qualifier used when assigning data set names for the installation and execution libraries.

mycart

Unit name for the cartridge device you are using.

mytvolser

Volume serial number of the CA SCM for Mainframe Installation cartridge. See the Release Notes for the specific volume serial number. For example, replace mytvolser with B1200C for the base installation of r12.

3. Submit the JCL.

When the job is complete, the installation JCL and control statements are loaded and ready to be customized.

4. Review the readme file, included in the myiprf.myiqual.INSTALL data set, for any last-minute information.

3-How to Edit the INSTALL Data Set


3-How to Edit the INSTALL Data Set The third step in the installation process is to edit the myiprf.myiqual.INSTALL data set. The myiprf.myiqual.INSTALL data set includes the following members: BC1JJB01, BC1JJB02, BC1JJB03 and README.

BC1JJB01 contains a job stream that allocates and initializes the CA SCM for Mainframe and SMP/E environments.

BC1JJB02 contains a job stream that populates the CA SCM for Mainframe and SMP/E environments.

BC1JJB03 contains a job stream that performs global change commands against several of the installation source libraries.

README contains installation notes and comments.

Perform the following steps to edit the members of the myiprf.myiqual.INSTALL data set:

1. Edit the BC1JJB01 member to customize it to the naming conventions in effect at your site, and then submit for execution to allocate and initialize all SMP/E and CA SCM for Mainframe data sets (see page 39).

2. Edit the BC1JJB02 member to customize it to the naming conventions in effect at your site, and then submit for execution to populate the SMP/E environment (see page 40).

3. Edit the BC1JJB03 member to customize it to the naming conventions in effect at your site, and then submit for execution to perform global change commands against several of the installation source libraries (see page 41).

Note: The myiprf.myiqual.INSTALL data set includes a readme file that might contain installation notes and information on important features. Before continuing, be sure to read this file.

Edit and Run BC1JJB01

Sample member BC1JJB01 is provided in myiprfx.myiqual.INSTALL.

Before you run job BC1JJB01, you must change the following variables:

mydvolser

Volume serial number of the disk used to store permanent data sets.

myiprfx

Highest-level qualifier used when assigning data set names for installation and execution libraries.



myiqual

Second-level qualifier used when assigning data set names for installation and execution libraries.

mypdisk

Unit label for permanent disk data sets.

mysmpfx

Highest-level qualifier used when assigning data set names for BASE CA SCM for Mainframe SMPE files.

mysmqul

Second-level qualifier used when assigning data set names for BASE CA SCM for Mainframe SMPE files.

mytdisk

Unit label for temporary disk data sets.

myuprfx

Highest-level qualifier used when assigning data set names for CA SCM for Mainframe user files.

myuqual

Second-level qualifier used when assigning data set names for CA SCM for Mainframe user files.

myvvolser

Volume serial number of the disk on which VSAM data sets are stored.

Note: Space requirements are based on 3390-type disk storage. If you use another type of device, adjust the SPACE parameter accordingly. For more information about space requirements, see Data Set Space Requirements.

After you have tailored the JCL, be sure you have a valid JOB statement and submit job BC1JJB01 for execution.


Sample member BC1JJB02 is provided in myiprfx.myiqual.INSTALL.

Before you run BC1JJB02, you must change the following variables:

mycart

Unit name for the cartridge device you are using.



myiprfx


myiqual


mysvolser

Volume serial number used by SMP/E for DD SMPTLIB. The SMP/E DD SMPTLIB is a dynamically allocated work file and requires a VOLSER. This is an IBM requirement.

mytdisk


mytvolser

Volume serial number of the CA SCM for Mainframe installation cartridge.



Sample member BC1JJB03 has been provided. It can be found in myiprfx.myiqual.INSTALL. This job performs global edits against some of the SMP/E target (runtime) libraries created by BC1JJB01 and populated by BC1JJB02, using the CA SCM for Mainframe program SCMUPDTE. For more information about SCMUPDTE, see SCMUPDTE Program Considerations (see page 45).

Note: Only values to the right of the “<” on the data input lines should be changed, values to the left of the “<” are in delivered members and must not be changed.

Change the following variables in BC1JJB03 to reflect the conventions in effect at your site. These changes are required for all users. After you have made the appropriate changes, save the updated member.

mycart

Unit name for cartridge device you are using.



mydvolser

Volume serial number of the disk used to store permanent data sets.

If your site does not require the use of the VOL=SER parameter when storing permanent data sets, make sure that the two lines in BC1JJB03 that eliminate this parameter are enabled (this is the delivered setting).

If your site does require this parameter, delete the two lines that eliminate this DVOLSER and enable the line that changes DVOLSER to MYDVOLSER, providing the your site’s value for DVOLSER.

myiprfx


myiqual


mypdisk

Unit label for permanent disk data sets.

mysvolser

Volume serial number used by SMP/E for DD SMPTLIB. The SMP/E DD SMPTLIB is a dynamically allocated work file and requires a VOLSER. This is an IBM requirement.

mytdisk


mytvolser

Volume serial number of the CA SCM for Mainframe installation cartridge.

myuprfx

Highest-level qualifier used when assigning data set names for CA SCM for Mainframe user files.



myuqual

Second-level qualifier used when assigning data set names for CA SCM for Mainframe user files.

myvvolser

Volume serial number of the disk on which the VSAM data sets will be allocated.

If your site does not require the use of the VOLUMES parameter when allocating VSAM data sets, make sure that the line in BC1JJB03 that comments this parameter out is enabled (this is the delivered setting).

If your site does require this parameter, delete the line that comments out the VOLUMES parameter and enable the line that changes VVOLSER to MYVVOLSER, providing the your site’s value for VVOLSER.

Change BC1JJB03 Member Command Variables (Sample Application)

If you are installing the sample application, you must change the following variable names to reflect the conventions in effect at your site. After you make the appropriate changes, save the updated member. Default values are supplied for all of these variables.

Note: For more information about installing and using the sample application, see The Sample Application (see page 59).

Edit the following variables:

ADPROC?

Indicates whether processors are in use at your site.

If your site received an LMP key for product A9, Extended Processors, enable the line that sets ADPROC? to ADPROC (this is the delivered setting).

If your site did not receive an LMP key, delete the line that sets this value to ADPROC and enable the line that sets ADPROC? to ADNOPROC.

MONITOR=COMPONENTS

Indicates whether ACM is in use at your site.

If your site did not receive an LMP key for ACM, enable the line that changes MONITOR=COMPONENTS to MONITOR=NONE.

SYSMACLIB

The data set name of the system assembler macro library. For example, SYS1.MACLIB. As delivered, this value is set to SYS1.MACLIB.



Change BC1JJB03 Member Command Variables (Sample Application and Extended Processors)

Your site may be using one or more types of extended processors. The sample application installs one COBOL and assembler processor.

The following variables must be changed in BC1JJB03 as appropriate for your site for the sample application to install properly. BC1JJB03 uses the SCMUPDTE syntax to globally change these values (left of the “<”) to what is desired (right of the “<”). For more information about SCMUPDTE, see SCMUPDTE Program Consideration (see page 45).

C??

This indicates the version of COBOL in use at your site, either COBOL II or COBOL/LE.

If you are using COBOL/LE, change this value to CLE.

If you are using COBOL II, change this value to CII.

If your site uses both COBOL/LE and COBOL II, change the value to the version of COBOL you use most often.

CLE is the delivered default.

C??NBL

CIINBL or CLENBL. Indicates the default processor group for COBOL elements delivered with the sample application. The C?? portion of this variable should be set to the same value as the variable C??. CLENBL is the delivered default.

SYSCLECOMP

The COBOL/LE compiler load library. For example, IGY.SIGYCOMP. IGY. SIGYCOMP is the delivered default.

SYSCLERUN

The z/OS Language Environment runtime library. For example, CEE.SCEERUN. CEE.SCEERUN is the delivered default.

SYSCLELKED

The z/OS Language Environment Automatic Call (link) library. For example, CEE.SCEELKED. CEE.SCEELKED is the delivered default.

SYSCIICOMP

The COBOL II compiler load library. For example, SYS1.COB2COMP. SYS1.COB2COMP is the delivered default.



SYSCIILIB

The COBOL II Automatic Call (link) library. For example, SYS1.COB2LIB. SYS1.COB2LIB is the delivered default.


SCMUPDTE Program Considerations

The SCMUPDTE program is used by BC1JJBO3 to perform global edits on some of the SMP/E target libraries created by BC1JJB01 and populated by BC1JJB02.

SCMUPDTE executes in one of the following modes:

Non-update execution mode–When the update execution parameter is not used, the PDSE members are not updated, but all reporting is produced, simulating what would have occurred during an update mode execution.

Update execution mode–When the update execution parameter is specified, all members of the input PDSEs are searched for string1 and replaced by string2.

During execution mode, SCMUPDTE performs edits on the PDSEs as follows:

– String1:

String1 is all of the characters up to the first less than sign (<) of the input (sysin) parameter.

String1 must be fully contained in positions 1 thru 71 of the input record and must be a "word" to be eligible for replacement.

String1 is considered to be a "word" if it is both preceded and followed by any of the following characters:

' , . / < > ? " : ; ^ + _ ( ) * % | = and blank.

– String2:

String2 is all of the characters after the first less than sign (<) and up to the second less than sign.

String2 can be of equal, greater, or less length than string1 and can be null.

– Any characters after the second < are treated as line comments and are ignored.

– If columns 1 through 3 contain the characters </*, the entire line is treated as a comment.

– The maximum number of input parameters that can be specified is 40 (comment lines are not counted).



– Syntax:

The maximum number of combined characters for string1 and string is 70.

The input parameter statements cannot be continued.

Data in columns 72-80 is ignored and unchanged

– Supported input library characteristics:

lrecl=80,recfm=f(b) and the first character of the ddname(s) must be "@"

Copy Include Members to a JES PROCLIB Library

Job BC1JJB03 tailored two members that reside in the iprfx.iqual.JCLLIB library. The names of the members are SCMM@LIB and SCMM@SYM. SCMM@LIB contains the runtime STEPLIB/CONLIB DD statements and SCMM@SYM contains a list of JCL SET statements defining symbolic parameter values. These members get included in other CA SCM for Mainframe job streams at runtime. Copy both of these members to a JES PROCLIB library. These members must be made available to CA SCM for Mainframe jobs at runtime.

If you do not want to move these members to a JES PROCLIB library, an alternative method is to place a JCLLIB statement in each job stream prior to executing it. The JCLLIB statement can be placed following the job card statements. One or more libraries can be identified on this statement. An example JCLLIB statement follows:

//ENDVR02A JOB (41200000),'DUMMY JOBCARD',

// REGION=4096K,CLASS=A,MSGLEVEL=(1,1),

// MSGCLASS=X

// JCLLIB ORDER=(iprfx.iqual.JCLLIB,uprfx.uqual.INCLUDE)

//--------------------------------------------------------

Two members named SCMM@LIB and SCMM@SYM also exist in the iprfx.iqual.ISPSLIB runtime library. These two members contain the same information as the members in the JCLLIB library, but the format of the data is a little different because they are included in ISPF skeleton members using the IM (Include Member) command. These members must remain in the iprfx.iqual.ISPSLIB runtime library.

4-Installation Considerations


4-Installation Considerations The fourth step in the CA SCM for Mainframe base installation process is to review the installation considerations. These considerations are organized into the following categories:

Authorized library considerations (see page 47)

LINKLST/LPA considerations (see page 48)

Determining LPA load module storage requirements (see page 49)

Global resource sharing considerations (see page 54) (if your site has multiple CPUs sharing DASD)

Concurrent CA SCM for Mainframe releases considerations (see page 57)

ISP Command table considerations (see page 58)

Authorized Library Considerations

The iprfx.iqual.AUTHLIB and uprfx.uqual.AUTHLIB data sets are allocated by job BC1JJB01 and populated by job BC1JJB02. The load modules contained in iprfx.iqual.AUTHLIB and uprfx.uqual.AUTHLIB must reside in a system-authorized library. You can authorize the libraries in the following ways:

Copy the members from the AUTHLIB libraries to an existing authorized library.

Authorize the iprfx.iqual.AUTHLIB and uprfx.uqual.AUTHLIB libraries.

If a LINKLST library is used, it is likely that the data set is authorized. If an LPA library is used, it is authorized.



LINKLST/LPA Considerations

You can copy the members of iprfx.iqual.AUTHLIB, iprfx.iqual.CONLIB, and uprfx.uqual.AUTHLIB to an existing LINKLST or LPA defined library. Alternatively, you can define these data sets as LINKLST or LPA libraries themselves.

Only reentrant load modules can be executed from the LPA. Before copying a library's contents to an LPA defined library or defining a library as an LPA library, inspect the members and move those that are non-reentrant to a LINKLST-defined library.

To determine which members are non-reentrant, use the ISPF Browse facility and follow these steps:

1. Display an ISPF browse member selection list for the load library.

2. Issue the SORT ATTR command.

3. Scroll to the right to see the Attributes column.

Note: Most members show attributes of RN RU, for reentrant and re-useable.

4. Members showing spaces instead of RN are non-reentrant and cannot be moved into the LPA.

How to Use LINKLIST or LPA Libraries for the AUTHLIB Data Sets

If you use LINKLIST or LPA libraries for the AUTHLIB data sets, do the following:

1. Remove the STEPLIB DD statements from the CA SCM for Mainframe sample job streams.

2. Remove, or comment out, the STEPLIB DD statements in the SCMM@LIB members in JCLLIB and ISPSLIB.

If you use the LINKLST and LPA libraries for the iprfx.iqual.CONLIB data set, do the following:

1. Remove the CONLIB DD statement from the sample job streams.

2. Remove, or comment out, the CONLIB DD statements in the SCMM@LIB members in JCLLIB and ISPSLIB.



How to Determine LPA Load Module Storage Requirements

To determine storage requirements for LPA-eligible load modules, use the ISPF Browse facility and follow these steps:

1. Display an ISPF browse member selection list for the load library.

2. Issue the SORT ATTR command.

3. Scroll to the right to see the Attributes column.

4. Eliminate all programs where the reentrant attribute is blank, because these programs cannot be placed into the LPA.

5. Issue the SORT RMODE command.

To determine the amount of storage required, follow one of these methods:

For 24-bit storage, add the hexadecimal value found in the Size field for all programs containing the value 24 in the RM (RMODE) field.

For 31-bit storage, add the hexadecimal value found in the Size field for all programs containing the value ANY in the RM (RMODE) field.

5-How to Define CA SCM for Mainframe to the ISPF Environment



The fifth step in the CA SCM for Mainframe installation process is to define CA SCM for Mainframe to the ISPF environment. You must identify the CA SCM for Mainframe data sets to ISPF, using either a CLIST or existing logon procedures.

Before you define CA SCM for Mainframe to the ISPF environment , consider the following information:

Many factors influence the region size required to execute CA SCM for Mainframe. These factors include split-screen processing, the use of CA Panvalet or CA Librarian, the maximum size of elements, whether sort work areas are defined in the CLIST, and whether ISPF resides in the LPA. A region size of 4096KB is sufficient for most installations.

The CLIST library delivered is fixed block (FB). If your existing CLIST libraries are variable blocked (VB), use the TSO utilities to create a VB file.

To identify the data sets to ISPF, do the following:

1. Identify the files to ISPF using one of the following methods:

Use the ISPF LIBDEF Services. (We recommend this method.)

Use the TSO FREE and ALLOCATE CLIST services to reallocate the ISPF libraries.

Allocate all data sets through TSO logon procedures.

2. Define an ISPF option for CA SCM for Mainframe to the main ISPF dialog by adding CA SCM for Mainframe as a valid option on an ISPF primary or secondary options panel.

3. Execute the CLIST.

The CLIST is executed automatically when you select the CA SCM for Mainframe option from the ISPF main dialog.

More information:

The ISPF LIBDEF Services Method (see page 51) The TSO FREE and ALLOCATE Method (see page 53)



The ISPF LIBDEF Services Method

You can use the ISPF LIBDEF services to identify CA SCM for Mainframe libraries to the ISPF environment. Use the CLIST member ENDEVOR provided on the installation cartridge in the ISRCLIB library. We recommend this approach.

Copy the CLIST to a data set that is allocated to the standard SYSPROC DD concatenation.

If the authorized CA SCM for Mainframe load modules have not been placed in LPA, LINKLST, or STEPLIB libraries, you can use the ISPF ISPLLIB DD statement as a substitute. However, allocation of an authorized library under ISPLLIB may not support all necessary system authorization requirements. Allocate ISPLLIB to the CA SCM for Mainframe authorized load libraries prior to invoking ISPF.

The CLIST you see at your site is an edited version, reflecting the information entered during the installation of the INSTALL job. After you create the CLIST, change an ISPF primary or secondary options panel to include an option for CA SCM for Mainframe.



Modify your ISPF panel similar to the following.

As previously illustrated, the ISPF/PDF Primary Option Menu has added option E for CA SCM for Mainframe. When you select this option, the CA SCM for Mainframe CLIST is invoked to begin the CA SCM for Mainframe dialog. The first line in the highlighted text indicates what to enter to select CA SCM for Mainframe. The second line indicates that the CA SCM for Mainframe CLIST should be executed when the defined option is selected.



The TSO FREE and ALLOCATE Method

You can use the TSO FREE and ALLOCATE services to identify CA SCM for Mainframe libraries to the ISPF environment. Use the CLIST provided on the installation cartridge, member BC1PCLS1 in the ISRCLIB library.

The CLIST must be copied to a data set in the standard SYSPROC DD concatenation and must be invoked at LOGON time.

The CLIST you see at your site is an edited version, reflecting the information entered during the installation of the INSTALL job.

Modify your ISPF panel similar to the following panel:



As previously illustrated, after you define the CLIST, you must change an ISPF primary or secondary options panel to include an option for CA SCM for Mainframe. In the illustration, the ISPF/PDF Primary Option Menu has added option E for CA SCM for Mainframe. Whenever you select this option, CA SCM for Mainframe is automatically invoked. In the highlighted lines, the first line indicates what to enter to select CA SCM for Mainframe. The second line indicates that the CA SCM for Mainframe program should be executed when the defined option is selected.

The TSO Logon Procedure Method

You can allocate the CA SCM for Mainframe data sets through your existing TSO logon procedures. Allocate the data sets as follows:

DDname Library Created by the INSTALL Job

SYSPROC iprfx.iqual.ISRCLIB

ISPPLIB iprfx.iqual.ISPPLIB

ISPSLIB iprfx.iqual.ISPSLIB

ISPMLIB iprfx.iqual.ISPMLIB

CONLIB iprfx.iqual.CONLIB (if not in LINKLIST or LPA)

ISPTLIB iprfx.iqual.ISPTLIB

After you copy these libraries to the logon procedure, change an ISPF primary or secondary options panel to include an option for CA SCM for Mainframe.

Note: For more information about how to add an option for CA SCM for Mainframe, see The TSO FREE and ALLOCATE Method (see page 53).

Global Resource Sharing Considerations

If your site has multiple CPUs sharing DASD, you need to define queue names. If you are using Unicenter CA-MIM Resource Sharing or IBM Global Resource Serialization (GRS), include the queue names in the appropriate Global Resource Queue Name Table.

Unicenter CA-MII ENQ Management Definitions

The Unicenter CA-MII component of Unicenter CA-MIM has two operating modes, ALLSYSTEMS mode and SELECT mode. The ENQ management definitions for CA SCM for Mainframe that you need to add in the Unicenter CA-MII MIMQNAME parameter library member depend on which mode Unicenter CA-MII is operating.



To determine which operating mode your active Unicenter CA-MII address space is running in, issue the Unicenter CA-MIM command “F MIM,D INIT” and review the results. To determine if PROCESS=ALLSYSTEMS or PROCESS=SELECT is in effect, review the MIM1019I command response message.

ALLSYSTEMS Processing Mode

If you are running Unicenter CA-MII in ALLSYSTEMS mode, add the following ENQ management definitions for CA SCM for Mainframe in the Unicenter CA-MII MIMQNAME parameter library member.

CTLIELEM GDIF=YES,

SCOPE=SYSTEMS,

EXEMPT=NO,

ECMF=YES,

RPTAFTER=30,

RPTCYCLE=60

CTLIPROC GDIF=YES,

SCOPE=SYSTEMS,

EXEMPT=NO,

ECMF=YES,

RPTAFTER=30,

RPTCYCLE=60

ENDEVOR GDIF=YES,

SCOPE=SYSTEMS,

EXEMPT=NO,

ECMF=YES,

RPTAFTER=30,

RPTCYCLE=60

SPFEDIT GDIF=YES,

SCOPE=SYSTEMS,

EXEMPT=YES,

ECMF=YES,

RPTAFTER=0,

RPTCYCLE=60

SYSIEWLP GDIF=YES,

SCOPE=SYSTEMS,

EXEMPT=NO,

ECMF=YES,

RPTAFTER=30,

RPTCYCLE=60



SELECT Processing Mode

If you are running Unicenter CA-MII in SELECT mode, add the following ENQ management definitions for CA SCM for Mainframe in the Unicenter CA-MII MIMQNAME parameter library member.

CTLIELEM GDIF=YES,

SCOPE=SYSTEMS,

EXEMPT=NO,

ECMF=YES,

RPTAFTER=30,

RPTCYCLE=60

CTLIMSTR GDIF=YES,

SCOPE=SYSTEMS,

EXEMPT=NO,

ECMF=NO

CTLIPROC GDIF=YES,

SCOPE=SYSTEMS,

EXEMPT=NO,

ECMF=YES,

RPTAFTER=30,

RPTCYCLE=60

ENDEVOR GDIF=YES,

SCOPE=SYSTEMS,

EXEMPT=NO,

ECMF=YES,

RPTAFTER=30,

RPTCYCLE=60

SPFEDIT GDIF=YES,

SCOPE=SYSTEMS,

EXEMPT=YES,

ECMF=YES,

RPTAFTER=0,

RPTCYCLE=60

SYSIEWLP GDIF=YES,

SCOPE=SYSTEMS,

EXEMPT=NO,

ECMF=YES,

RPTAFTER=30,

RPTCYCLE=60



GRS Definitions

There should be no reason to have the INCL (include) statements, because a global enqueue is also issued along with the RESERVE. Using the CON will convert the RESERVE so there is no hardware RESERVE on the volume and by default GRS will include the SCOPE=SYSTEMS enqueue for global propagation.

Only the QNAMES of SPFEDIT, SYSIEWLP and CTLIMSTR are used with RESERVE W/SCOPE=SYSTEMS + UCB locks. The remaining QNAMES, CTLIPROC, ENDEVOR, and CTLIELEM are used with ENQUEUE W/SCOPE=SYSTEMS.

/***********************************************************/

/* RESOURCE NAME LIST FOR CA-ENDEVOR */

/***********************************************************/

RNLDEF RNL(CON) TYPE(GENERIC) QNAME(CTLIMSTR)

RNLDEF RNL(CON) TYPE(GENERIC) QNAME(SPFEDIT)

RNLDEF RNL(CON) TYPE(GENERIC) QNAME(SYSIEWLP)

Concurrent Release Considerations

In many cases, it is necessary to run two different releases of CA SCM for Mainframe at the same time. You can do this by adding your AUTHLIB and CONLIB to the respective STEPLIB and CONLIB statements in a test TSO logon procedure. Member SCMM@LIB in both the ISPSLIB and JCLLIB installation libraries were tailored by BC1JJB03 of the installation process to point to your STEPLIB/CONLIB concatenations. The Skeleton JCL members installed imbed ISPSLIB member SCMM@LIB to point to your STEPLIB/CONLIB concatenations. Stand-alone JCL members include JCLLIB member SCMM@LIB for your STEPLIB/CONLIB concatenations. The JCLLIB member SCMM@LIB can be copied to a JES PROCLIB or a JCLLIB statement can be added to each stand-alone JCL member to point to the library where this member resides.

You cannot access both releases in the same TSO/ISPF session. After working with one release, before you can work with the other, you must log off TSO and log on again, making sure to change the logon procedures. If you do not change your logon procedures, a message indicates an incompatible C1DEFLTS Table.

Important! You can share CA SCM for Mainframe r12 MCFs between r12 and r7, provided you also share the element catalog. However, the following r12 features are not backward compatible: automatic element version rolling, promotion packages, and processor map allocation.



ISP Command Table Considerations

CA SCM for Mainframe uses an ISP Command table (allocated under the ISPTLIB DD) for some commands (such as ESORT, EONLY, EPRINT, ACMQ, BC1PACMI, EMSGS, and so on). However, unless this facility is specifically enabled, it may be prevented from working by your site's security package. For example, CA ACF2 has a facility named TSO Command Limiting, which may need modification.

Implementing the Sample Application 59

Chapter 3: Implementing the Sample Application


The Sample Application (see page 59) How to Implement the Sample Application (see page 61) Additional Sample Jobs (see page 84)

The Sample Application Important! If you are installing CA SCM for Mainframe for the first time, you must implement the sample application. If CA SCM for Mainframe is already installed at your site, you can skip this chapter. Use your existing inventory and life cycle for testing purposes. For more information, see How to Test New Releases with Your Data (see page 85).

The CA SCM for Mainframe sample application is provided as a training tool to help you understand how to implement CA SCM for Mainframe. The sample application reflects a basic software life cycle, including examples of a life cycle definition, inventory definitions, and processors, all of which can be useful to you during your site's implementation of CA SCM for Mainframe.

The sample application presents one way of implementing CA SCM for Mainframe, which may be different from the way that you have implemented it at your site. It may include steps that you do not perform or it may present steps in a different order.

Before you implement the sample CA SCM for Mainframe application at your site, be sure that CA SCM for Mainframe has been installed successfully.

The Sample Application


Sample Application Naming Conventions

The following is the naming conventions for the files used by the sample application.

iprfx.iqual.SMPLssss.xxxxxxxx

iprfx

Specifies the highest-level qualifier (1-8 characters in length) for the CA SCM for Mainframe and sample application libraries and files; for example, SYS3. This value was defined as part of the global edits performed prior to running the CA SCM for Mainframe installation process.

iqual

Specifies the second-level qualifier (1-8 characters in length) for the CA SCM for Mainframe and sample application libraries and files; for example, ENDEVOR.

SMPLssss

Specifies the identifier used together with the stage name (indicated by the ssss ) to construct the third qualifier as follows:

– TEST-For Stage 1 of SMPLTEST (unit test)

– QA-For Stage 2 of SMPLTEST (quality assurance)

– EMER-For Stage 1 of SMPLPROD (emergency fixes)

– PROD-For Stage 2 of SMPLPROD (production stage)

For example, if during the installation process you changed iprfx to SYS3 and iqual to ENDEVOR, your data sets would be named as follows:

– SYS3.ENDEVOR.SMPLTEST.xxxxxxxx

– SYS3.ENDEVOR.SMPLQA.xxxxxxxx

– SYS3.ENDEVOR.SMPLEMER.xxxxxxxx

– SYS3.ENDEVOR.SMPLPROD.xxxxxxxx

xxxxxxxx

Specifies the fourth-level qualifier of the data sets used for the sample application and represents the type of data contained in the file; for example, MCF for the master control file, PACKAGE for the package control file, and so on.

Important! File names are limited to a total of 44 characters, including periods. The maximum length of each data set name qualifier is eight characters.

How to Implement the Sample Application


How to Implement the Sample Application To implement the sample application, perform the following basic tasks:

1. Edit the CA SCM for Mainframe Defaults Table (C1DEFLTS) (see page 61).

2. Define and allocate CA SCM for Mainframe libraries (see page 64).

3. Define the CA SCM for Mainframe inventory structure and populate it with an application (see page 70).

4. Verify the implementation (see page 71).

5. Perform ACM Query Facility verification. (see page 83)

All JCL and source members used in the implementation steps and the processors for the sample environments are included in the CA SCM for Mainframe iprfx.iqual.SAMPLE library created during the installation process. The members in this library were customized according to the values you supplied in installation job BC1JJB03.

Defaults Table (C1DEFLTS)

The CA SCM for Mainframe Defaults Table contains processing and environment definition information for your site. The table is comprised of a set of macros which, when assembled and link-edited, are known collectively as the C1DEFLTS Table. The types of C1DEFLTS macros are distinguished by the following TYPE keyword parameters:

One TYPE=MAIN parameter is required for each site, to define general site-specific information. The TYPE=MAIN macro is the first macro in the definition of the table.

Any number of TYPE=ENVRNMNT macros can be included in the table. You must have one TYPE=ENVRNMNT macro for each environment in your configuration. The TYPE=ENVRNMNT macros follow the TYPE=MAIN macro in the definition of the table.

One TYPE=END macro is needed to indicate the end of the table definition. It follows the last TYPE=ENVRNMNT macro.



1-How to Edit C1DEFLTS

The sample application C1DEFLTS table is in the library iprfx.iqual.SAMPLE, in member SMPLDEFT. For the sample application, do the following:

1. Enter site-specific parameters in the TYPE=MAIN macro section of the C1DEFLTS table. Enter or edit the parameter values, as appropriate.

Important! Be sure the iprfx.iqual values you assign to data set names in the C1DEFLTS Table match those you defined as part of the global edits performed during installation. For more information, see The Variable Definitions Table (see page 12).

2. Verify MCF qualifiers in the TYPE=ENVRNMNT macro.

For the purposes of the sample application, you cannot change anything in the TYPE=ENVRNMNT macro. Instead, verify that the qualifiers for the Master Control File (MCF) data sets match those specified during the global edits. The data set name is supplied during the definition of the sample application data sets.

Note: For more information, see How to Define and Allocate CA SCM for Mainframe Libraries. Be sure to use the same data set names when allocating these data sets in job SMPLJOB2. For more information, see Run SMPLJOB2.

3. Run SMPLDEFT

After you have edited the sample defaults table, you need to assemble and link-edit it. If you have not already done so, copy your JOBCARD member to the beginning of member SMPLDEFT in iprfx.iqual.SAMPLE, then submit the job for execution. Store the load module in your authorized library as member C1DEFLTS. After you have implemented and worked with the sample application and you are ready to build your own life cycle, use member C1DEFLTS in iprfx.iqual.TABLES.

The site-specific parameters in the TYPE=MAIN macro are as follows:

ACMROOT

(Required if you are using ACM) Names the data set name of the VSAM file your site will use to store the name of each CA SCM for Mainframe element and all its related components. This data set is required if your site is licensed to use ACM.

The data set name is supplied during the definition of the ACM Query data sets. For more information, see Allocating and Initializing ACM Query Files (SMPLACMD) (see page 68). Be sure and use this same data set name when allocating these data sets in job SMPLACMD.

If you are not using ACM, remove the data set name; for example: ACMROOT=,

Note: For more information about ACM, see the Automated Configuration Option Guide.



ACMXREF

(Required if you are using ACM) Names the data set name of the VSAM file you will use to store the name of each component relationship. This data set is required if your site is licensed to use ACM.

The data set name is supplied during the definition of the ACM Query data sets. For more information, see Allocating and Initializing ACM Query Files (SMPLACMD) (see page 68). Be sure and use this same data set name when allocating these data sets in job SMPLACMD.

If you are not using ACM, remove the data set name; for example: ACMXREF=,

Note: For more information about ACM, see the Automated Configuration Option Guide.

ASCM

Specifies a value, Y or N, to indicate whether your site is licensed for the Automated Configuration Option (ACM) facility.

If you received an LMP key for Product AY, ACM, enter Y. Otherwise, enter N.

CUNAME

Names the 1-50 character name that describes your site. This name is used in report headings.

ELMCATL

Names the 1-44 character data set name for the Element Catalog. The name is supplied during the definition of the Element Catalog. For more information, see Allocate the Master Control Files, Element Catalog, Base, Delta, and Output Libraries. Be sure to use the same name when defining the Element Catalog in SMPLJOB2. CA SCM for Mainframe incorporates the use of an Element Catalog file to support long element names and to improve performance by reducing the volume of I/O operations.

LIBENV

Do not change the value of LIBENV until after running SMPLJOB4, regardless of whether you received an LMP key for this feature.

MACDSN

Names the SOURCE library at your site that contains the CA SCM for Mainframe macros (iprfx.iqual.SOURCE).



PKGDSN

(Required if using packages) Names the package file for your site. The name is supplied during the definition of the package file. For more information, see How to Define and Allocate CA SCM for Mainframe Libraries (see page 64). Be sure and use this same data set name when allocating the package data set in SMPLJOB1. For more information, see Run SMPLJOB1.

PROC

Specifies a value, Y or N, indicating whether your site is licensed for CA SCM for Mainframe Extended Processors. If your site received an LMP key for Product A9, Extended Processors, enter Y. Otherwise, enter N.

SITEID

Names the 1-character name that identifies your site. This field is used internally to differentiate between sites. The default is 0 (zero).

Important! The SITEID is an integral part of the CA SCM for Mainframe footprint. Any changes to this parameter for existing CA SCM for Mainframe applications will result in a footprint-compromised error for each element within that environment.

VIOUNIT

Names the unit name for temporary disk data sets that are stored on a virtual I/O unit.

WRKUNIT

Names the unit name for temporary disk data sets that are not stored on a virtual I/O unit.

Note: For more information about all items that appear in the TYPE=MAIN portion of the C1DEFLTS Table, see the Administration Guide. Reference that guide when creating your own C1DEFLTS Table.

2-How to Define and Allocate Your Libraries

You must define and allocate the following libraries for the sample application:

The Package File.

The Master Control File.

The Element Catalog.

The Base, Delta, and Output Libraries.



Use members SMPLJOB1 and SMPLJOB2, which are stored in iprfx.iqual.SAMPLE, to allocate these files.

Important! The VSAM files used by CA SCM for Mainframe, the Master Control files, the Element Catalog, and the package file must be maintained at a two-level index for file integrity purposes. CA SCM for Mainframe automatically recognizes if a file has less than two index levels and dynamically adjusts it. The next user to access CA SCM for Mainframe will not encounter a similar problem.

How to Allocate the PACKAGE FILE

The PACKAGE FILE is a VSAM data set that stores all packages built to perform element actions in any of the environments defined in the C1DEFLTS Table. Only one package data set can exist per site.

To allocate the PACKAGE FILE, do the following:

1. Defined the PACKAGE FILE in the C1DEFLTS Table. Be sure the name of the PACKAGE FILE allocated is the same as the name provided in the PKGDSN parameter in the C1DEFLTS Table.

Note: For more information, see Enter Site-Specific Parameters in the TYPE=MAIN Macro (see page 62).

This step allocates the following VSAM structure:

Library Data Set Name

VSAM cluster iprfx.iqual.SMPL.PACKAGE

VSAM cluster containing data iprfx.iqual.SMPL.PACKAGE.DATA

VSAM cluster containing indexes

iprfx.iqual.SMPL.PACKAGE.INDEX

2. If you have not already done so, copy your JOBCARD member to the beginning of SMPLJOB1, and then submit the job for execution. Member SMPLJOB1 is stored in iprfx.iqual.SAMPLE and is used to allocate this file.

When you run SMPLJOB1, the JCL completes the following steps:

Executes IDCAMS to delete any existing package files the first time you run this job.

Defines the (new) package file.



Master Control File

An environment in CA SCM for Mainframe is made up of two stages; a unique MCF is required for each. The MCF values are defined to CA SCM for Mainframe using the STG1VSAM and STG2VSAM parameters in the TYPE=ENVRNMNT section of the C1DEFLTS Table. The MCF stores the system, subsystem, type, and element definitions for the stage. Be sure the iprfx.iqual components of the Master Control File data set names are the same values as the data set names coded in the C1DEFLTS table.

Element Catalog

CA SCM for Mainframe incorporates the use of an Element Catalog file to support long element names and to improve performance by reducing the volume of I/O operations. It is identified to CA SCM for Mainframe by the ELMCATL parameter in the TYPE=MAIN section of the C1DEFLTS Table.

Base, Delta, and Output Libraries

The base, delta, and output libraries are used during CA SCM for Mainframe execution. Base libraries store the original or current source version of an element. Delta libraries track the differences between the numerous source levels of an element. Source output libraries contain readable copies of an element; for example, JCL, PROC, COPYBOOK, and data parameters. Processor output libraries contain executables; for example, load libraries, object decks, and DBRMs. CA SCM for Mainframe uses Processor load libraries to store the executable version of a processor.

Note: For more information about base and delta libraries, see the Administration Guide. For more information about processors, see the Extended Processor Guide.

You can have multiple occurrences of the libraries in the following list, usually one set of libraries for each stage. Only two processor load libraries are allocated-one for each production stage where the processor type is defined.

The base, delta, and output libraries that you can allocate include (but are not limited to) the following:

Source (base) library

Delta library

Copy library

Object library

Load library

Listing library



Link-edit control card library

JCL library

JCL procedure library

DBRM library (for DB2 users)

How to Run SMPLJOB2

SMPLJOB2 defines the Master Control Files (MCF), the Element Catalog, and any base, delta, and output libraries used by the sample application. It deletes any existing libraries before allocating them.

SMPLJOB2 is found in the CA SCM for Mainframe JCL library, iprfx.iqual.SAMPLE. If you have not already done so, copy your JOBCARD member to the beginning of SMPLJOB2, and then submit the job for execution. If the job is interrupted or terminates abnormally, restart the job from the beginning.

When you run SMPLJOB2, the JCL performs the following actions:

1. DELMCF executes IDCAMS to delete any Master Control Files that exist.

2. DEFMCF executes IDCAMS to define the (new) Master Control Files.

3. DELECATL executes IDCAMS to delete the sample Element Catalog, if one exists.

4. DELEIX executes IDCAMS to delete the Element Catalog cross-reference file.

5. DEFECATL executes IDCAMS to define the (new) sample Element Catalog.

6. DEFEIX executes IDCAMS to define the Element Catalog cross-reference file.

7. DELPDS executes IDCAMS to delete the non-VSAM (base, delta, and output) libraries before they are reallocated.

8. DEFPDS executes IEFBR14 to allocate the non-VSAM (base, delta, and output) libraries.



How to Allocate and Initialize ACM Query Files (SMPLACMD)

Important! If your site does not have a license for ACM, skip this step and continue with the Implementation Checklist (see page 69).

You must define and initialize the sample application ACM Root (ACMROOT) and Cross-reference (ACMXREF) files used by the ACM Query Facility (ACMQ) if you specified ASCM=Y. ASCM=Y indicates that you are using the Automated Configuration Manager at your site.

To define and initialize the ACMROOT and ACMXREF files, do the following:

1. Use member SMPLACMD, located in iprfx.iqual.SAMPLE, to define the Root and Cross-reference data sets.

The ACMQ Root data set contains the name of each element used as an input component to other elements, as well as all related components. The ACMQ Cross-reference data set contains a record for each component relationship.

These files are defined to CA SCM for Mainframe in the ACMROOT and ACMXREF parameters in the TYPE=MAIN section of the C1DEFLTS Table. There is only one ACMROOT and ACMXREF pair of data sets per site.

2. Make sure that the name of the allocated ACMROOT and ACMXREF files are the same as the names provided in the ACMROOT and ACMXREF parameters in the C1DEFLTS Table.

Note: For more information about these parameters, see Enter Site-Specific Parameters in the TYPE=MAIN Macro (see page 62).

Library Data Set Name

VSAM cluster ipfrx.iqual.SMPL.ACMROOT

VSAM cluster iprfx.iqual.SMPL.ACMXREF

Note: For more information about ACMQ, see the Automated Configuration Option Guide.



How to Define and Initialize the Root and Cross-reference Data Sets

Use member SMPLACMD, located in iprfx.iqual.SAMPLE, to define (create) the Root and Cross-reference data sets used by the sample application.

1. Edit member SMPLACMD to add a valid jobcard and verify that the cluster names and the VOLUMES parameter are what you expect. These values were customized according to the values you supplied in installation job BC1JJB03.

2. Follow the instructions in SMPLACMD to further edit the JCL and submit the JOB to create and initialize the sample application root and cross-reference data sets.

Note: After you have finished using the sample application and you are ready to build your production CA SCM for Mainframe application, use JCLLIB member BC1JACMD to build your production ACMQ files.

Implementation Checklist

Before implementing the rest of the sample application, ensure that you have installed CA SCM for Mainframe correctly. Ask yourself the following questions, which reflect typical problems that might occur when installing the sample application.

Have your LMP keys been installed?

Have all CA SCM for Mainframe-supplied libraries been created and populated? Do they contain the correct number of modules? (For example, AUTHLIB 60+, CONLIB 700+)

Have the MCFs, Element Catalog/EINDEX, and Package File been created correctly?

Are TYPE=MAIN, TYPE=ENVRNMNT, and TYPE=END present and in the correct order in the CA SCM for Mainframe C1DEFLTS Table?

If the AUTHLIB is not being placed in the linklist, did you add a STEPLIB to the proper JCL skeletons, LOGON procs, and CLISTs?

If AUTHLIB is in the linklist, did you perform an LLA REFRESH after creating the C1DEFLTS table in Step 1?

Test system authorization for NDVRC1. Is the AUTHLIB authorized? Depending upon the release of TSO, has the NDVRC1 keyword been added to the proper system tables?

Can CA SCM for Mainframe find and load NDVRC1, C1DEFLTS, and any other programs that typically reside in the AUTHLIB/CONLIB?



3-How to Define the Sample Application Inventory Structure (SMPLJOB3)

You define the sample application inventory structure (systems, subsystems, types) to CA SCM for Mainframe by executing the Batch Environment Definition Facility (also known as Batch Admin).

Note: For more information about using the Batch Environment Definition Facility, see the SCL Reference Guide.

To execute the Batch Environment Definition Facility, do the following:

1. Use the JCL from SMPLJOB3, which is in the library iprfx.iqual.SAMPLE.

2. If you have not already done so, copy your JOBCARD member to the beginning of SMPLJOB3, and then submit the job for execution.

In the SMPLJOB3 JCL, notice the last two lines. The second-to-last line refers to member SCLXTND and is uncommented. The last line refers to member SCLBASE and is commented out.

3. If your site is using extended processors, do nothing. Otherwise, uncomment the SCLBASE, ddname ENESCLIN line and comment out the line specifying member SCLXTND by adding //* to the front of that line.

SCLXTND contains SCL to define system FINANCE, subsystems ACCTPAY and ACCTREC, and several types such as COBOL, ASM, and COPY, as well as several processor groups for each of these types. These definitions are made to both stages of the SMPLTEST and SMPLPROD environments. The FINANCE system is where the source elements used by the sample application are stored. An additional system, ADMIN, is defined to the SMPLPROD environment. This system contains one subsystem and one type - PROCESS. This is where the processors used by the sample application are stored.

SCL contains SCL similar to SCLXTEND in that it defines the same systems, subsystems, and types. It differs in the respect that no processor groups are defined.

4. If this step does not complete satisfactorily (return code greater than 08), research the error, then rerun SMPLJOB2 before running SMPLJOB3 again.

Note: To quickly find the error message associated with an RC=12, view the job's output in SDSF or another output management utility, page down to the C1MSGS1 output, and on the COMMAND line type F 'E ' 19 ALL and press ENTER. An ENBEnnnE message is displayed. For more information about this message, see the Error Codes and Messages Guide.



Populate the Sample Application (SMPLJOB4)

You can add processors and source data to the sample application. Use the JCL member SMPLJOB4, which is in the library iprfx.iqual.SAMPLE. This job adds elements to the application and, if your site is using processors, adds the sample processors and generates the elements.

If you have not already done so, copy your JOBCARD member to the beginning of SMPLJOB4, then submit the job for execution. If this step does not complete successfully, perform a restart at the step where termination occurred.

Note: This job may exceed the output line limit. Submit the job appropriately.

When you run SMPLJOB4, the JCL performs the following actions.

1. Adds processors to the sample application, if your site is using them.

2. Adds elements to the sample application.

3. Moves all elements to SMPLPROD stage 2.

4-How to Verify the Implementation

After you have performed the installation steps and executed the sample application implementation jobs, you need to verify that the sample environments have been created correctly. The following information summarizes the verification process:

1. Be sure that the sample jobs have completed successfully. If a job has failed to execute successfully, you must rerun that job or, in some situations, restart from a step that failed within the job.

2. Start CA SCM for Mainframe. Check the Environment Selection panel to ensure that the environments SMPLTEST and SMPLPROD appear (see page 72).

3. Execute CONRPT02, the System Inventory Summary and review it to ensure that all sample application elements have been loaded (see page 72).

4. Run foreground (see page 75), batch (see page 80), and ACMQ verification procedures (see page 83).



View the Environment Selection Panel

Ask your system administrator how CA SCM for Mainframe has been identified to ISPF. Typically, this is done as an ISPF menu option.

Select the CA SCM for Mainframe option from the appropriate ISPF panel. With the sample application properly implemented, the CA SCM for Mainframe Environment Selection panel displays the sample environments as options. You should see options for both the Sample Test Environment and the Sample Production Environment.

View the System Inventory Summary Report

To verify that all elements were correctly added to CA SCM for Mainframe, view CONRPT02, the System Inventory Summary Report, for the SMPLPROD environment. Review the report to verify that the number of elements in SMPLPROD is correct.

To view the System Inventory Summary Report

1. Start CA SCM for Mainframe using the instructions provided by your site administrator.

The Primary Options panel appears.

2. Select U (User Menu), and press Enter.

The User Options Menu appears.

3. Select Option 1, Reports, and press Enter.

The Reporting Interface panel appears.

4. Select option 1, Master, and press Enter.

The Master Control File Reports panel appears.

5. Select 02, System Inventory Summary, and enter the following values.

ENVIRONMENT

Enter SMPLPROD

SYSTEM

Enter an asterisk (*)

SUBSYSTEM


ELEMENT




TYPE


STAGE


SEARCH ENVIRONMENT MAP

Enter N

6. Press Enter.

CA SCM for Mainframe generates JCL to create CONRPT02, the System Inventory Summary, for environment SMPLPROD. The CA SCM for Mainframe Reporting Interface panel opens, displaying the message, Job Step Created, in the upper right of the panel.

7. Select option S, Submit, and press Enter.

CA SCM for Mainframe submits the JCL for execution and displays the message, Job Submitted, in the upper right hand corner of the panel.

Compare the output from the System Inventory Summary you generate to the following sample report. The values on your report should match the sample report values.

If any discrepancies exist between your report and the sample report, review the output from SMPLJOB4. Look for any error messages that might have occurred. Correct the problems, resubmit SMPLJOB4, and run CONRPT02 again.



Example: View the System Inventory Summary Report

Your System Inventory Summary should appear as follows:



If you ran SMPLJOB3 using SCLBASE as input, your report should look similar to the following report:

Verify the Sample Environments (Foreground)

You must verify, in foreground mode, that the sample environments have been loaded correctly.

To verify that the sample environments have been loaded correctly



2. Select option 2, Foreground, and press Enter.

The Foreground Options Menu appears.

3. Select option 4, Generate.

The Generate Elements panel appears.

4. Enter the following values.

ENVIRONMENT

Enter SMPLPROD

SYSTEM

Enter FINANCE



SUBSYSTEM

Enter ACCTREC

ELEMENT

Enter FINARP01

TYPE

Enter COBOL

STAGE

Enter P

COMMENT

Enter VERIFY

DISPLAY LIST

Enter Y

BUILD USING MAP

Enter Y

CCID

Enter SAMPLE

COPYBACK

Enter N

OVERRIDE SIGNOUT

Enter N

5. Press Enter.

CA SCM for Mainframe compiles and links program FINARP01. If the sample environments have been installed correctly, the message ELEMENT FINARP01 GENERATED appears in the upper right corner of the Generate Elements panel.

If the action fails, review the execution report, which is automatically generated, to determine the nature of the problem. If it fails because of errors during the compile or link steps, research the problem using the stored compile and link-edit listings.



View a Stored Listing (Foreground)

You must verify, in foreground mode, that a stored listing has been loaded correctly.

To view a stored listing



2. Select option 1, Display, and press Enter.

The Display Options Menu appears.

3. Select option 2, Footprint, and press Enter.

The Footprint Display Panel appears.

4. In the OTHER PARTITIONED DATA SET field, enter iprfx.iqual.SMPLPROD.LISTLIB and press Enter.

A list of members in that library appears.

5. Tab down to, or issue a locate command for, member FINARP01.

6. Enter L to the left of the member you want to select and press Enter.

The stored listing is displayed. Review the listing for compile and link errors.



The following listing is an example of a stored listing.

******************************** Top of Data **********************************

*******************************************************************************

*******************************************************************************

**

** FFFFFFFFFFFF IIIIIIIIII NN NN AAAAAAAAAA RRRRRRRRRRR PPPPP

** FFFFFFFFFFFF IIIIIIIIII NNN NN AAAAAAAAAAAA RRRRRRRRRRRR PPPPP

** FF II NNNN NN AA AA RR RR PP

** FF II NN NN NN AA AA RR RR PP


** FFFFFFFF II NN NN NN AAAAAAAAAAAA RRRRRRRRRRRR PPPPP

** FFFFFFFF II NN NN NN AAAAAAAAAAAA RRRRRRRRRRR PPPPP


** FF II NN NNNN AA AA RR RR PP

** FF II NN NNN AA AA RR RR PP

** FF IIIIIIIIII NN NN AA AA RR RR PP

** FF IIIIIIIIII NN N AA AA RR RR PP

**

*******************************************************************************

*******************************************************************************

*****************************************

*****************************************

** ******** GENERATE ********

**

** USER ID......... USER02

** DATE............ 24OCT02 16:02

** ENDEVOR RC...... 0000

**

** ENVIRONMENT..... SMPLPROD

** STAGE........... PROD

** SYSTEM.......... FINANCE

** SUBSYSTEM....... ACCTREC

** ELEMENT......... FINARP01

** VV.LL........... 01.00

** TYPE............ COBOL

** PROC GROUP...... CLENBL

** PROCESSOR....... GCIINBL

** STEP1......... RC=0000

** CONWRITE...... RC=0000

** CONWRIT2...... RC=0000

** CONRELE....... RC=0000

** COMPILE....... RC=0000

** LINK.......... RC=0004

**

*****************************************



PP 5648-A25 IBM COBOL for OS/390 & VM 2.2.1

Invocation parameters:

LIB,NOSEQ,OBJECT,APOST,

Options in effect:

NOADATA

ADV

NOANALYZE

APOST

ARITH(COMPAT)

NOAWO

BUFSIZE(4096)

NOCICS

.

.

. PP 5648-A25 IBM COBOL for OS/390 & VM 2.2.1 FINARP01 Date

10

LineID PL SL ----+-*A-1-B--+----2----+----3----+----4----+----5----+----6---

000001 000100 IDENTIFICATION DIVISION.

000002 PROGRAM-ID. FINARP01.

000003 000300 ENVIRONMENT DIVISION.

000004 INPUT-OUTPUT SECTION.

000005 000500 FILE-CONTROL.

000006 SELECT REPORT-FILE ASSIGN U-T-SYSOUT.

000007 SELECT INPUT-FILE ASSIGN U-T-INPUT.

000008 000700 DATA DIVISION.

000009 000800 FILE SECTION.

000010 FD REPORT-FILE

000011 LABEL RECORDS ARE OMITTED

RECORDING MODE IS F

.

.

.

ENTRY POINT AND ALIAS SUMMARY:

NAME: ENTRY TYPE AMODE C_OFFSET CLASS NAME STATUS

FINARP01 MAIN_EP ANY 00000000 B_TEXT

***** E N D O F R E P O R T *****



OS/390 V2 R10 BINDER 16:03:40 THURSDAY OCTOBER 24, 2002

BATCH EMULATOR JOB(TURKA02 ) STEP(CATSO ) PGM= IEWL PROCEDURE(CATSO )

IEW2008I 0F03 PROCESSING COMPLETED. RETURN CODE = 4.

---------------------

MESSAGE SUMMARY REPORT

---------------------

SEVERE MESSAGES (SEVERITY = 12)

NONE

ERROR MESSAGES (SEVERITY = 08)

NONE

WARNING MESSAGES (SEVERITY = 04)

2520

INFORMATIONAL MESSAGES (SEVERITY = 00)

2008 2278 2322

**** END OF MESSAGE SUMMARY REPORT ****

******************************* Bottom of Data *******************************

Verify the Sample Environments (Batch)

You must verify, in batch mode, that the sample environments have been loaded correctly.

To verify that the sample environments have been loaded correctly



2. Select option 3, Batch, and press Enter.

The Batch Options Menu appears.



3. Enter the following values:

PROJECT

Enter a qualifier for any 80-byte partitioned data set. For example, MCCPE01.

GROUP

Enter a qualifier for any 80-byte partitioned data set. For example, PGM.

TYPE

Enter a qualifier for any 80-byte partitioned data set. For example, SCL.

MEMBER

Enter SCLVER

4. In the Option field, enter 1, and press Enter.

The SCL Generation menu appears.

5. Select option 4, Generate, and press Enter.

The Generate Elements panel appears.

6. Enter the following values:

ENVIRONMENT

Enter SMPLPROD

SYSTEM

Enter FINANCE

SUBSYSTEM

Enter ACCTREC

ELEMENT

Enter FINARP01

TYPE

Enter COBOL

STAGE

Enter P

COMMENT

Enter VERIFY

CCID

Enter SAMPLE



COPYBACK

Enter N

OVERRIDE SIGNOUT

Enter N

7. Enter G in the Option field, and press Enter.

The message SCL GENERATED displays in the upper right corner of the panel.

8. Press PF3 twice.

The Batch Options Menu appears.

9. In the JOB STATEMENT INFORMATION field, enter your JOBCARD information.

10. Select option 3, Submit, and press Enter.

The job is submitted for execution and a message displays, confirming that the job was submitted.

Use SDSF, CA SYSVIEW® Realtime Performance Management, or a similar facility to view the batch job output. Check the last page for a return code of 0000. If the return code is 0000, the job executed successfully. If the return code is not 0000, review the execution report (which is generated automatically) to determine the problem.



5-Perform ACM Query Facility Verification

If you have not already done so, copy your JOBCARD member to the beginning of SMPLACMX in iprfx.iqual.SAMPLE, and then submit the job for execution. SMPLACMX performs a batch ACM query request that finds all programs that use copybook PAGING.

The output that you see should look similar to the following output:

Additional Sample Jobs


Additional Sample Jobs The CA SCM for Mainframe library iprfx.iqual.SAMPLE contains several JCL members that you can use in conjunction with the sample environments. A description of each job follows:

SMPLTRNG

Uses the SCL statements in iprfx.iqual.SAMPLE (TRNGSCL) to add 20 COBOL programs and copybooks for use in on-site training classes offered by CA. If you want, you can also add these elements for in-house training.

SMPLDEL

Executes IDCAMS and IEFBR14 to delete all the sample application files from disk.

SMPLGENR

Executes CA SCM for Mainframe Batch SCL to generate all elements in the sample application.

SMPLLIBR

Executes CA SCM for Mainframe Batch Admin SCL to update type definitions when using CA Librarian.

SMPLPANV

Executes CA SCM for Mainframe Batch Admin SCL to update type definitions when using CA Panvalet.

SMPLJREL

Executes CA SCM for Mainframe Batch Admin SCL to define new type definitions that can be used in conjunction with CONRELE in a processor to demonstrate the use of ACMQ to query on user-related information.

SMPLUNLD

Executes the CA SCM for Mainframe Unload Utility to back up the sample application data.

SMPLRELD

Executes the CA SCM for Mainframe Reload Utility to restore the sample application data (using Unload utility data as input).

Note: For more information about the Unload/Reload/Validate utility, see the Utilities Guide.

Testing New Releases with Your Data 85

Chapter 4: Testing New Releases with Your Data


How to Test New Releases with Your Data (see page 85)

How to Test New Releases with Your Data As an alternative to using the Sample Application, you can use your existing production data for testing upgrades to new releases of CA SCM for Mainframe. To do this, you must perform several post-installation steps to create a copy of the data on your test system. We recommend that you copy your largest and most active systems. If your site has many environments, you do not have to establish a test version of them all; however, you should use at least two mapped environments.

Using the following steps, you can make copies of your production MCFs and Package File, and make copies of all the base, delta, and output libraries associated with the systems you select. If you are changing the names of these files on the test system, or if you need to establish a test bed on your production system, you must update CA SCM for Mainframe with the new names.

Perform the following tasks to test new releases with your data:

1. Copy your Element Catalog (see page 86).

2. Copy the Master Control Files (see page 86).

3. Copy the Package File (see page 86).

4. Update your C1DEFLTS Table (see page 87).

5. Synchronize the Element Catalog with your MCFs (see page 87).

6. Copy ACMQ Files (see page 87).

7. Allocate Base, Delta, and Source Processor Output Libraries (see page 88).

8. Copy Production Data (see page 88).

9. Identify Test Libraries (see page 88).

10. Test the New Release (see page 89).

How to Test New Releases with Your Data


Copy Your Element Catalog

CA SCM for Mainframe incorporates an Element Catalog file to support long element names and to improve performance by reducing the volume of I/O operations. The Element Catalog file is required and only one is allowed per site. The Element Catalog is identified to CA SCM for Mainframe through the ELMCATL field in the TYPE=MAIN section of the C1DEFLTS Table.

To create your Element Catalog

1. Run job BC1JRCAT. You can find this member in the iprfx.iqual.JCLLIB that is delivered with the product.

2. Edit the job to ensure that Step 2 references your production ELMCATL and EINDEX, and that Step 3A, 3B, and 4 references the test catalog you want to create.

Copy the Master Control Files

To test with copies of your MCFs, use member BC1JRMCF located in iprfx.iqual.JCLLIB. This job will REPRO your current MCF files into sequential data sets; create your new MCF, and then REPRO the old data from the sequential files into your new files.

Edit the JCL to ensure that Step 2 references the MCFs you are copying from, and the remaining steps reference the test files you want to create.

Copy the Package File

To test using a copy of your existing package file, use member BC1JRPKG from your CA SCM for Mainframe JCL library. This job backs up your existing data set to a sequential file, deletes and redefines the package file, and then populates the records back into the newly-defined VSAM package file.

To test with a new package file

1. Create a new PDS member using only Step 3A in the JCL.

2. Submit it for execution.

3. Edit the JCL to ensure that Step 2 references your production package file, and that Step 3A and 3B through 5 references the test package file you want to create.



Update Your C1DEFLTS Table

Before you can use any of your newly copied files, you must first identify them to CA SCM for Mainframe through the C1DEFLTS table. When your updates are complete, assemble and link-edit the defaults table. Employ an SMP/E USERMOD to assemble and link-edit C1DEFLTS after you customize it. Alternatively, edit the sample JCL BC1JTABL to assemble and link source module C1DEFLTS outside of SMP/E. BC1JTABL is located in the installation library iprfx.iqual.JCLLIB. This stores the defaults table in uprfx.uqual.AUTHLIB as member C1DEFLTS.

The updated table must reside in the authorized library that was established during the installation process. Verify this information with the person who installed the product at your site.

Note: For more information about the C1DEFLTS Table, see How to Edit the Defaults Table (C1DEFLTS) (see page 61).

Synchronize the Element Catalog with Your MCFs

To ensure the Element Catalog that you just copied is properly referenced by the MCFs defined in your C1DEFLTS Table, you need to run job BC1JXCNM. Use member BC1JXCNM in irpfx.iqual.JCLLIB.

First, run the job with the VALIDATE execution parameter. If the job ends with RC=0 in VALIDATE mode, the element catalog and MCFs are synchronized. However, if it returns an RC=4, ensure you are using the correct C1DEFLTS. RC=4 can indicate that a mismatch exists between the Element Catalog and the C1DEFLTS. If your C1DEFLTS is correct, run BC1JXCNM with execution parameter UPDATE to fix the error. In this mode, the program examines all the MCFs defined in the C1DEFLTS table and stamps the MCFs with the Element Catalog data set name.

Copy ACMQ Files

If your site is licensed for Automated Configuration Manager, and you specify ASCM=Y in your C1DEFLTS Table, the ACM query files, ACMROOT and ACMXREF, must be allocated. If you want to make copies of your existing ACMQ files, you can use IDCAMS to REPRO them to a sequential file (attributes FB 4096) and then REPRO them back into your test files. To allocate new files, use job BC1JACMD, and then use BC1JACML to populate them.



Allocate Base, Delta, and Source Processor Output Libraries

After processing the MCFs, Package, ACMROOT, XREF and Element Catalog files, you need to allocate your data files. Using IEFBR14 or IDCAMS, allocate empty pds, pds/e or ELIBS, based on your site's implementation. Copy any base, deltas, source output libraries, processor output, and load libraries associated with the systems and types you plan to use in your testing.

Copy Production Data

Using IDCAMS, IEBCOPY, or BC1PNCPY, copy your production files over to the new empty test files.

Note: For more information about these utilities, see the Utilities Guide.

Identify Test Libraries to CA SCM for Mainframe

After you have copied all your production files to new empty test files, change the data set names from their production name values to their new test name values. Update the data set names in each stage for each system imported for testing under each environment.

To rename your production file names to your test file names



2. Select option 4, Environment, and press Enter.

The Environment Options menu appears.

3. Select option 8, DATASET, and press Enter.

The Type Data Set Request panel appears.

4. Enter the name of the system and stage identifier you want to update, enter U in the Option field, and press Enter.

The Type Data Sets panel appears.



5. To rename a data set, type over the existing name in the DATA SET NAME column.

Any error messages are displayed under the MSG column. Press F1 to get more information about an error message, or see the Error Codes and Messages guide.

6. Repeat these steps for both stages of each environment, for each system you copied.

Note: If you decide not to use your production data files for testing, you have the option of starting from scratch. To do this you need to create all new files, and run Batch Admin (ENBE1000) to build your new environment. For more information about the Batch Admin Utility, see the SCL Reference Guide.

Test the New Release

After you have updated all your systems and stages, you are ready to test. Be certain to test your exits, making sure that you reassemble and relink them first.

Implementation Considerations 91

Chapter 5: Implementation Considerations


Organizational and Technical Considerations (see page 91) Considerations for Organizational Change (see page 92) Considerations for Developing a Strategy (see page 92) Recommendations for Selecting an Implementation Team (see page 93) How to Introduce CA SCM for Mainframe to Your Development Team (see page 95) Recommendations for a Pilot Project (see page 98) How to Build Momentum for Your Implementation (see page 99)

Organizational and Technical Considerations Organizations can expect higher productivity, less production downtime, and better overall software quality shortly after implementing CA SCM for Mainframe. However, any change to organizational procedures requires careful project planning, education, awareness, management support, and internal selling.

To help assist and prepare you for a successful implementation, consider the following organizational and technical areas:

Considerations for Organizational Change (see page 92)

Considerations for Developing a Strategy (see page 92)

Recommendations for Selecting an Implementation Team (see page 93)

Considerations when Introducing CA SCM for Mainframe to your Development Team (see page 95)

Recommendations for Using a Pilot Project (see page 98)

Considerations for Organizational Change


Considerations for Organizational Change To assess how CA SCM for Mainframe will be received in your organization, consider the following points:

How large is your organization? Would you consider your organization small (50 developers or less), medium (50-200 developers), or large (more than 200 developers)?

How concise are the standards for software management now? Are they documented? Are they enforced? If the standards are not clear, what will it take for your organization to agree upon what the standards will be?

Will CA SCM for Mainframe be used extensively across groups within the organization? For example, will development, QA, and production turnover all use it?

Have all groups that will use CA SCM for Mainframe been involved in the evaluation and buying decision? If any of those groups were not involved in the original assessment, you may need to explain to them the benefits of CA SCM for Mainframe.

Are the organization's reasons for purchasing CA SCM for Mainframe clearly understood by all groups impacted by the purchase? Different levels of objectives include control, standardization, and the ability to audit.

Considerations for Developing a Strategy When all considerations are addressed, you need to develop a strategy for proceeding. Make decisions about the following issues:

How much of the implementation effort do you want to spend on organizational activities, such as education and internal selling? How much effort on technical activities, such as writing processors?

For an average size organization (approximately 100 developers), the ratio of time spent should be about 50/50. For larger organizations, the percentage of time spent on organizational issues must be higher.

How extensively should you document current procedures, and how much time is needed to define new procedures?

How do you get different groups to agree on a standardized set of procedures?

Recommendations for Selecting an Implementation Team


How much internal selling is needed to obtain management support for CA SCM for Mainframe in the organization?

What is the scope of the implementation? For example, should you implement source management first, and output and configuration management at a later time? Or, do you want a phased approach such as JCL for the entire organization, then copybooks, then COBOL, and so on?

Recommendations for Selecting an Implementation Team We strongly recommend that at least one full-time person is devoted to coordinating the CA SCM for Mainframe implementation effort. You can add more resources as needed. When selecting an implementation team, consider the following recommendations:

Technical Knowledge

You should select team members with the following technical and knowledge sets:

– IBM z/OS JCL

– Application development software (such as compilers, linkage editors, and so on)

– Utilities, report writers, and so on

– Operation and use of ISPF/PDF facilities

– Your security system (usually RACF, CA Top Secret, or CA ACF2)

– Audit requirements

– Testing and production standards and turnover procedures

– Applications to be implemented

– Current procedures (standard and emergency changes, approval procedures, and so forth)

Recommendations for Selecting an Implementation Team


Organizational Involvement

Ownership of CA SCM for Mainframe varies by organization. However, representatives from the following areas will probably be required for the implementation:

– Technical Services

System software specialists are needed to install and verify the installation. Operations analysts are needed to address JCL, production scheduling, and other general production turnover questions.

– Production Control

Representatives are needed to assist in automating the movement of new or changed software into production. This ensures that new procedures satisfy the business needs of the organization.

– Applications

At least one analyst from each application must be available during that application's implementation, to assist in application classification, compile procedures, training, and so on.

– Security Administration

An authorized person must define the appropriate security rules.

– Auditing

A person from the auditing department must ensure that audit requirements are defined and that the new procedures satisfy these requirements.

– Training and documentation

These groups need to be involved in developing training and internal documentation to support the system.

How to Introduce CA SCM for Mainframe to Your Development Team


Public Relations Knowledge

Some very large organizations have a dedicated person handling "public relations" work related to CA SCM for Mainframe. Based on how you want to handle this aspect of the implementation (that is, the need to gain acceptance from many parts of the organization), consider involving people with the following skills on the implementation team:

– Experience with the environment

Having an experienced person who understands the environment and is easy to communicate with is highly beneficial. This person should be able to relate to the production control and operations perspectives as well as the development and QA perspectives.

– Organizational skills

Often, a representative from the implementation team is asked to mediate discussions between different groups trying to derive standards for software management.


When your organization made the decision to acquire CA SCM for Mainframe, CA representatives most likely spent time with the people performing the evaluation, explaining how CA SCM for Mainframe could suit the needs of the organization. Whatever the scope of your implementation, the implementation team will probably have to do some internal selling as well. Management, production turnover staff, developers from different groups, auditors, the QA staff, and other groups will need to learn about and accept CA SCM for Mainframe before offering their support for the implementation.

The following recommendations may help you to introduce CA SCM for Mainframe to your team:

Plan on preparing a presentation to introduce CA SCM for Mainframe to the people in your organization who are not familiar with the product. Depending on the complexity of your organization, you may need to create several presentations. Your presentations should include items such as the following:

– A summary of the problems faced under the current software management procedures, and the justification for the acquisition of CA SCM for Mainframe. Whenever possible, use objective numbers and cost justifications, such as number of system outages per month due to software problems.

– An overview of CA SCM for Mainframe functionality.



– An explanation of how CA SCM for Mainframe will help your organization meet its goals.

– A brief explanation of the proposed CA SCM for Mainframe implementation, including a walkthrough of the software life cycle. As the presentation proceeds, explain the benefits and relate the solution to the problems identified above.

– Time frames for the implementation, and what is expected of the group you are addressing.

Tailor the Presentation

Tailor your presentation to your audience. For a presentation to higher-level management, for example, you may want to de-emphasize the life cycle and technical issues surrounding the implementation and focus on the resources required, the payback expected, and the time frames for implementation. For developers, focus on how CA SCM for Mainframe can increase their productivity by allowing them to view change history for their programs online, or show them how to use the footprint display panels to view source directly from load modules.

Emphasize goals in all presentations and public relations efforts. Work into each presentation the goals of productivity, availability of the production software environment, and any additional objectives for which CA SCM for Mainframe was acquired.

Introduce CA SCM for Mainframe to Your Organization

After the groundwork is in place for the implementation, it is time to introduce CA SCM for Mainframe to the various groups within the organization that will use the product and benefit from it. When making a presentation to the following groups, consider stressing the points indicated:

– Management

Management must accept the proposed implementation and give it the appropriate priority over other tasks. Inevitably, a manager has limited resources, so you must convince the manager that CA SCM for Mainframe is the best way to increase software quality and personnel productivity.

Show management that CA SCM for Mainframe improves productivity, improves software quality, and standardizes the software management process. You may want to discuss approvals and reporting, areas in which management may be involved with CA SCM for Mainframe.



– Development

It is important to show development personnel how CA SCM for Mainframe can improve the process of solving problems, viewing changes, preventing regression, and improving production availability which results in fewer late night phone calls. Show them that CA SCM for Mainframe can make their jobs easier by reducing software development and maintenance time.

– Production turnover

Show how CA SCM for Mainframe will automate the production turnover process, move source and executables together, facilitate backing out and addressing quick fixes, and provide a better audit trail of who made changes. CA SCM for Mainframe also enforces standards for things like JCL (by automating the invocation of JCL-checkers like JOB-SCAN) without the production staff's involvement. By the time a change gets to the production staff, they can be sure it has already passed standards.

– Audit

The audit group can have a great deal of influence over software management procedures, particularly in regulated industries. In addition to the other benefits of CA SCM for Mainframe, audit groups should be shown the change tracking, SMF recording, and footprinting features.

Emphasize that CA SCM for Mainframe can provide auditors with preventive controls rather than detective controls; that is, prevent the exception before it occurs rather than improve the process through which exceptions are detected.

After the presentation, keep in touch with the attendees to gain feedback from the presentation, to alert them when their particular group will be affected by the implementation process, and to address ongoing questions or concerns from them or anyone in their group.

Presentations are not the only way to introduce CA SCM for Mainframe to your organization. Additional implementation aids include the following:

CA sales materials

CA representatives are more than happy to provide sales materials that you can distribute to coworkers.

Recommendations for a Pilot Project


Demonstrations

You may want to use the supplied MVSTEST and MVSPROD environments to show people how CA SCM for Mainframe works. Use a simple demo (RETRIEVE, ADD, MOVE) to show functionality. Tailor your demo to the audience (for example, auditors would probably like to see footprinting, while developers would like to see online change history tracking).

Personal contact

Consider setting up a special phone number that people can call for answers to their questions about CA SCM for Mainframe. Have someone readily available to communicate reliable product and implementation information.

Recommendations for a Pilot Project One of the best ways to implement CA SCM for Mainframe is to start with a pilot application. No matter how you decide to approach the implementation (for source, output, or configuration management), a successful pilot can make the rest of the implementation easier.

The implementation of a pilot system has the following benefits:

Validates your software life cycle design and procedures.

Builds momentum and excitement about CA SCM for Mainframe within the organization.

A pilot application ideally has the following characteristics:

One system, two to four subsystems, and a good sampling of element types to be managed.

Approximately 200 - 400 or more elements, with the maximum amount of 1000. Remember that an element is any component that belongs to the application, whether it is a copybook, program, JCL, or other type.

Relatively little change activity.

Available personnel. Because this is the first application to be implemented, more time than usual may be required of the people involved with the pilot group.

You may want to rate several applications according to the above criteria to determine the best application to use as the pilot.

How to Build Momentum for Your Implementation


How to Build Momentum for Your Implementation Building momentum in the organization is a good way to keep the implementation process on track. In addition to implementing a successful pilot application, you can also build momentum by doing the following:

Talking CA SCM for Mainframe

For example, when you hear of a developer overlaying a colleague's code, do not hesitate to mention how the situation could have been avoided with CA SCM for Mainframe.

Using the pilot project as a reference

When people ask how CA SCM for Mainframe works, refer them to the pilot application staff to share their experiences.

Charting the progress of each group in the implementation effort

The following figure shows how you can accomplish this simply yet effectively, perhaps in the context of an implementation newsletter.

Many sites that have tried this approach found that it improved the motivation of teams that were on or ahead of schedule and those teams that were behind schedule.

Implementing CA SCM for Mainframe 101

Chapter 6: Implementing CA SCM for Mainframe

Note: The life cycle in this chapter, or a slight variation of it, is used by a majority of CA SCM for Mainframe implementations. It is the basis for the supplied MVSTEST and MVSPROD environments, and will be used when explaining data set naming conventions and other implementation considerations.


Implementations (see page 101) How to Implement for Source Management (see page 103) How to Implement for Output Management (see page 119) How to Implement for Configuration Management (see page 123) How to Finalize the Implementation (see page 123)

Implementations CA SCM for Mainframe is a fully functional software management tool. You can implement CA SCM for Mainframe to provide many levels of functionality, including:

Source management only (see page 103)

Output management and source management (see page 119)

Configuration management and source and output management (see page 123)

Implementation Prerequisites

Before you begin the CA SCM for Mainframe implementation, you must do the following to ensure your success:

Ensure that CA SCM for Mainframe is installed and the installation has been verified.

Ensure that the MVSTEST and MVSPROD environments provided on the installation cartridge are available.

Implementations


Ensure you are familiar with the basic CA SCM for Mainframe concepts.

Ensure that all of the CA SCM for Mainframe documentation is available for you to reference.

Plan backup and recovery procedures.

You should implement backup and recovery procedures, based on the information in the Utilities Guide.

Decide on the Implementation A Phased Implementation

Some sites implement the product in phases. In the first phase, a site might implement all applications for source management. In the next phase, the site implements each application for output management. A phased implementation of CA SCM for Mainframe has the following advantages:

– Inventory is established

– Signin and signout can be enabled

– Base (forward delta) or images (reverse delta) and change levels are available

– Benefits of source management are realized quickly

– Security is activated for all application source

– All personnel are trained at the same time on product functionality

A Full Implementation

Other sites implement each application for both source and output management. A full implementation of CA SCM for Mainframe includes the advantages of a phased implementation, in addition to the following:

– Online approvals are allowed

– Procedures are standardized

– The Automated Configuration Manager (ACM) is enabled

– Source can be related to executables

You must decide which type of implementation best suits the requirements of your site.

Note: As you proceed with the implementation, document the procedures you develop and the standards you use. This is important for the training phase that follows implementation.

How to Implement for Source Management


How to Implement for Source Management You may decide to implement CA SCM for Mainframe only for source management for the following reasons:

You do not want to use CA SCM for Mainframe to manage executables.

You plan a phased-in implementation of CA SCM for Mainframe.

You are looking for a quick replacement for your existing library management system.

To successfully implement CA SCM for Mainframe for source management, complete the following steps:

1. Define your software life cycle (see page 103)

2. Analyze your inventory (see page 108)

3. Define the logical structure to CA SCM for Mainframe (see page 109)

4. Define the physical structure to CA SCM for Mainframe (see page 111)

5. Define CCIDs (optional) (see page 115)

6. Enable package processing (see page 116)

7. Define site level type sequencing (optional) (see page 118)

After you complete these steps, you can continue with the next section, How to Implement CA SCM for Mainframe for Output Management (see page 119), or if you are implementing CA SCM for Mainframe for source management only, perform the Final Implementation Steps (see page 123).

1-How to Define Your Software Life Cycle

Software life cycles are site-specific. To determine the best life cycle for your site, you need to spend as much time as necessary to accomplish the following:

Understand and document current procedures

Develop procedures for normal and emergency processing

Understand current library configuration and ownership

Reach consensus on software management objectives

Determine the Stages for Control

Determine which stages of the life cycle you want CA SCM for Mainframe to control. You can put some, or all, of the stages in your life cycle under control of CA SCM for Mainframe.



Define the Environments

Environment is the CA SCM for Mainframe term for functional areas in your organization. The following illustration shows how environments are set up in the CA SCM for Mainframe sample application (which represents a typical life cycle).

The unit testing (UT) and quality assurance (QA) stages in the life cycle are part of the development function. Problem fixes (INT) and production applications (PRD) are part of the production function. The administrator defines environment MVSTEST to include Stage UT and Stage QA, and environment MVSPROD to include Stage INT and Stage PRD. Development activities take place in a development library, outside of CA SCM for Mainframe.

Define the Map

Applications in each life cycle follow a unique route through the environment and stage locations you have defined. You can set up as many routes as you need to accommodate different life cycles at your site. These routes make up the map for your site. CA SCM for Mainframe uses these routes to automate the processes of adding, displaying, retrieving, moving, and generating inventory in a particular life cycle.



The CA SCM for Mainframe administrator might decide to establish a route for inventory at this site that promotes the inventory from Stage UT to Stage QA to Stage PRD.

Important! You enter the first environment in the map through the entry stage. This example has Stage 1 defined as the entry stage. Stage 1 always maps to Stage 2 of the environment. You can, however, map Stage 2 of one environment to Stage 1 or Stage 2 of the next environment. A map route must always exit an environment from Stage 2. The route can enter either Stage 1 or Stage 2 of the next environment.

Typical Development Procedures

Typical development proceeds as follows:

1. Retrieve inventory from Stage PRD to the development library

2. Work on the inventory and add it into Stage UT

3. Promote the inventory along the map to Stage QA and eventually back to Stage PRD

Quick Fix or Emergency Procedures

Quick fixes or emergencies are handled as follows:

1. Retrieve inventory from Stage PRD to a maintenance library

2. Work on the inventory and add it into Stage INT

3. Promote the inventory to Stage PRD or have the INT types compile directly into override emergency libraries



Parallel Development Map

For a parallel development situation, many users find it advantageous to create an additional route, for long-term development use. The following illustration shows a map in these situations that has two routes:

Note: For more information about defining a map, see the Administration Guide.

Define Master Control Files

You will need one Master Control File (MCF) for each stage in your software life cycle. For example, the MVSTEST and MVSPROD environments each have two stages, and therefore a total of four Master Control Files. These are VSAM data sets. The following is the suggested naming conventions:

NODE1

User-defined (for example, CA ENDVR)

NODE2

Stage ID

NODE3

MCF

NODE4

INDEX or DATA (this node is supplied by the system)



Example: VSAM Cluster Name for a Master Control File

The following is an example of a VSAM cluster name for a Master Control File:

ENDEVOR.TEST.MCF

In this example, the following information applies:

Occurrence. One per stage.

Size. Approximately five cylinders per 1000 elements to be maintained.

Format. VSAM

Where defined. In the CA SCM for Mainframe Defaults Table (C1DEFTLS)

Environment Implementation Checklist

When defining your environments and map, be sure you do the following:

1. Set up routes that reflect your software life cycle. Draw a diagram of the routes first, using the previous examples as models.

2. Establish the routes in the CA SCM for Mainframe Defaults Table. The environments in the routes must appear in the same order (top-down) as they were established in the map. For example, you set up the following map route:

TEST->QA->PROD

These environments must appear in the Defaults Table in the following order:

TEST

QA

PROD

3. Edit the CA SCM for Mainframe Defaults Table. Make sure that you edit the table to include your Master Control File data set definitions.

Make sure that the appropriate site options are correctly specified. For example, if you plan to implement CA SCM for Mainframe for configuration management, ensure that the Automated Configuration Manager (ACM) is enabled in the CA SCM for Mainframe Defaults Table.

Important! Do not activate the Interface for External Security until you complete the required preparatory steps.



2-Analyze the Inventory

In this step, you classify your current inventory. First you must decide, in broad terms, how you want to classify your inventory. You can classify inventory in the following groups:

Business function (Applications, Tools, Systems)

Application group (Finance, Human Resources)

Another method

A typical way of structuring your inventory is to classify your inventory by application group (for example, Finance), and by application within this group (for example, Accounts Payable). This structure maps to the system, subsystem structure of CA SCM for Mainframe, and is the format used in the sample application.

You also need to categorize the application components with which you are working; for example, JCL, COBOL source, or copybooks. This categorization maps to types in CA SCM for Mainframe.

You can use the Inventory Analyzer to identify the different kinds of components that exist in your current inventory and to classify them according to CA SCM for Mainframe types and processor groups. The reports produced by the Analyzer are a useful way to identify the types and processor groups that you need to define to CA SCM for Mainframe.

Note: For more information about the Inventory Analyzer, see the Inventory Analyzer Guide.

You can also use the Inventory Analyzer, along with your data set or member naming conventions, to classify your inventory into the CA SCM for Mainframe logical structure (system and subsystem) that you decide to use.

Important! If you are using security, the inventory structure you implement may impact the security rules that you have to define. Enabling security is one of the final implementation steps.



3-Define and Implement the Logical Structure

You can implement your logical structure using the following processing methods:

Online—Processes in real time, and options pop up immediately.

Batch—Processes in the background, and creates a template that you can use repeatedly to define your inventory structure.

Combination of online and batch—Simplifies implementation. This is the type of implementation described in this guide.

Note: If you decide not to use the combination of methods, it is recommended that you implement your logical structure using batch processing.

Based on the inventory grouping that you have designed in Steps 1 and 2, you can now define your logical structure to CA SCM for Mainframe.

Note: Before actually defining the logical and physical structures, write down the proposed naming standards for the logical structure and libraries, and review them to make sure the structures are consistent and meet your needs.

To implement the logical structure using a combination of online and batch processing, do the following:

1. Build an environment by defining a system, subsystem(s), type(s) and processor group(s) for a subset of your inventory. Do so online by selecting the ENVIRONMENT option from the Primary Options Menu (define a small subset of model definitions; for example, define 1 system, 1 subsystem, 1 type, and 1 processor group).

2. Once the environment is built, use the batch environment BUILD SCL action to create DEFINE SCL for the environment.

3. Modify the SCL created above to create the definitions for the remainder of your inventory structure.

If you decide not to use the combination of methods, we recommend that you implement your logical structure using batch processing.

Note: For more information about online implementation, see the Administration Guide. For more information about batch implementation, see the SCL Reference Guide.



Define Systems

When defining systems to CA SCM for Mainframe, you must do the following:

Define a system to each environment in which you plan to use the system.

Define at least one subsystem to each system.

You can map systems across environments.

Define Subsystems

You must define a particular subsystem to each system in which you plan to use the subsystem.

You can map subsystems across environments.

Define Types

If you used the CA SCM for Mainframe Inventory Analyzer, it has indicated most or all of the types you should define. Remember the following:

You must define types to each system and stage combination in which you plan to use them. All subsystems defined to a system can use the types defined to that system.

You can map types across the environment/stage locations in your map.

Note: Mapping system, subsystem, or type names allows these names to change automatically as source moves up the map. For more information about mapping system, subsystem, and type names, see the Administration Guide.

Type Naming Conventions

Consider using generic type names, such as COBOL. You can then create as many processor groups as you need to handle the variations within each type. For example, for type COBOL, you could create a processor group for each type of COBOL that must be processed.

Note: For more information about processor groups, see the Extended Processors Guide.

The following information provides suggested naming standards for types. This information is not complete and is provided as a guideline only.

ASM LINKCARD SORTCNTL PORTRAN

BASIC MACRO SPECS RPG

CLIST MARKV TABLES JCL



ASM LINKCARD SORTCNTL PORTRAN

COBOL NETRON TELON REPORTS

COPYBOOK PLI TRNSFORM SCL

EASYTREV PROC UTILITY

The Inventory Analyzer uses these naming conventions for types.

Verify the Definitions

After you have defined your logical structure to CA SCM for Mainframe, run CONRPT07, System Definition Profile, to verify that you have set up the correct definitions. You should also run CONRPT07 whenever you change a map route, to verify that you have made the modifications correctly.

4-Define the Physical Structure

In this step, you create a physical data set structure to support the logical structure you have just defined. For any CA SCM for Mainframe implementation, you must define and allocate Master Control Files and base and delta libraries.

If you plan to use CA SCM for Mainframe packages, you must also define and allocate a package data set (see page 117).

Base and Delta Library Naming Conventions

Use the following suggested naming conventions when defining your base and delta libraries. These libraries typically are partitioned data sets or of another standard partitioned organization.

NODE1

System

NODE2

Stage ID

NODE3

Base Delta

Example: Base Library Name

FINANCE.TEST.BASE



Using Symbolics to Define CA SCM for Mainframe Libraries

CA SCM for Mainframe allows you to define base, delta, source output, and Include libraries using symbolics. The library name in the previous example could be written as:

&C1SYSTEM..&C1STAGE..BASE

When you define this data set using symbolics, the definition is reusable for multiple type definitions. The symbolics you can use are listed in the following table:

Organize Libraries By Using this Symbolic Or this Alias

Site &C1SITE N/A

Environment &C1ENVMNT &C1EN

Stage &C1STAGE &C1ST

Stage1 &C1STAGE1 &C1ST1

Stage2 &C1STAGE2 &C1ST2

Stage ID &C1STGID &C1SI

Stage 1 ID &C1STGID1 &C1SI1

Stage 2 ID &C1STGID2 &C1SI2

Stage number &C1STGNUM &C1S#

System &C1SYSTEM &C1SY

Subsystem &C1SUBSYS &C1SU

Type &C1ELTYPE &C1TY

Use these symbolics when specifying base and delta libraries on type definition panels. CA SCM for Mainframe replaces the symbolic with the proper information from the action request.

Example: Use a Symbolic

In this example, the library name refers to a library called SRCLIB for each subsystem and stage combination within a given system.

&C1SYSTEM..&C1SUBSYS..&C1STGID..SRCLIB



Occurrence

We recommend that you allocate at least one base/delta library pair per system per stage for all components that are not needed in PDS format outside of CA SCM for Mainframe (for example, compiled source).

Note: For components that are needed in PDS format outside of CA SCM for Mainframe, see Library Definition (see page 114).

Base and delta libraries can be shared across stages within the same environment.

Sizing

To estimate the size of these data sets, use the Disk Space Requirements Worksheet (see page 18).

For directory sizing and data set maintenance information, see the Utilities Guide.

Format

Base and delta libraries can be in PDS, PDS/E, ELIB, CA Panvalet, or CA Librarian format. In addition, the base library can also be an HFS directory, however, the delta library cannot.

Note: For more information about ELIB data sets, see the Utilities Guide.

Element Storage Formats

You can store elements in either reverse delta or forward delta format.


In reverse delta format, the element base is the current image of the element. CA SCM for Mainframe recreates previous levels of the element by applying delta levels to this base. All previous changes to the element are maintained in the delta library.

We recommend this format for CA SCM for Mainframe base product users. We also recommend that you use reverse delta format for types when the current level of the element might be used by another process. For example, a COPYBOOK or a COBOL program might be used as part of a compile process; or JCL may be submitted for execution.



If you select this format, you can store the element base as is (unencrypted), or encrypted and compressed:

– Unencrypted

Source is directly readable by programs outside of CA SCM for Mainframe, such as compilers.

Base/delta format is the same as regular PDS format, eliminating the need for source output libraries.

List and query functions perform more efficiently.

– In encrypted and compressed format

You receive DASD savings of 10-40%.

A single base library can contain multiple elements with the same name, but different system, subsystem, or type specifications.

Important! If you select the reverse delta storage format, CA SCM for Mainframe does not allow two unencrypted elements with the same name to be stored in the same base library. Keep this in mind when planning your inventory structure. In addition, a source output library is required if elements will be backed out.

Forward Delta

In forward delta format, the element base is the source form of the element when it is first added into CA SCM for Mainframe. When CA SCM for Mainframe processes elements stored in this format, it applies all delta levels to the base to create the current image of the element.

If you select this format, CA SCM for Mainframe encrypts and compresses both the base and subsequent deltas, with the same advantages of encryption and compression that occur for reverse delta format.

Library Definition

CA SCM for Mainframe libraries are defined on the Type Definition panel or using the DEFINE TYPE SCL.

Base and Delta Library Considerations

Consider the following information when using base and delta libraries:

If you plan to use the Automated Configuration Manager (ACM), increase size estimates by 20 percent and double the number of directory blocks.

If you decide to use reverse delta format, increase the size estimate of the delta library by 30 percent and triple the number of directory blocks. The increased size is necessary because both the base and delta members for the component lists are stored in the element's delta library.



The LRECL for base and delta libraries must be set to 255.

If you decide to use reverse delta format, only the delta library LRECL must be set to 255.

Before allocating the base and delta libraries, you must make a decision regarding the format in which you want to store element source and change history.

Backup and Recovery

Planning backup and recovery procedures is a very important part of implementation. You should implement backup and recovery procedures, based on the information in the Utilities Guide.

5-Define CCIDs (Optional)

CA SCM for Mainframe change control identifiers (CCIDs) most often correspond to mechanisms such as work order requests or request-for-service numbers. If your site uses this type of mechanism, consider implementing CCIDs.

If you decide to implement CCIDs, you must make the following decisions:

Do you want to simply make the tool available, without validation or administration?

Do you want to predefine CCIDs so they can be validated? Predefining CCIDs allows you to do the following:

– Validate CCIDs entered by users against the predefined CCIDs.

– Associate user IDs or specific inventory areas with a CCID.

CCID Definition Data Set

If you decide to validate CCIDs, you must allocate a CCID Definition data set. Suggested naming conventions include the following:

NODE1

project

NODE2

data set

NODE3

type



An example of a CCID Definition data set is following:

ENDEVOR.CCIDVAL.SAMCIPO

Occurrence

One per site

Size

This data set is usually quite small-if you allocate one primary track with one secondary extent, you should have enough space

Format

Sequential

Where defined

In the Defaults Table

Note: For more information about CCIDs and CCID validation, see the Administration Guide.

6-Enable Package Processing

Packages are the online approval mechanism within CA SCM for Mainframe. If you want to replace or upgrade your existing approval system (for example, a paper system), packages are an excellent way to do so.

Packages allow you to do the following:

Create sets of actions that can be tracked, maintained, and reused as a unit.

Establish approval procedures for packages.

Ship package outputs to remote locations.

Note: For more information about packages and approver groups, as well as shipping package outputs, see the Packages Guide.

Set Up a Package Naming System

Decide on a naming convention for packages. For example, you may want to increment package numbers sequentially. Or, you might want to include codes that indicate which group or application is using a particular package, or which CCIDs are involved with a package.



Define and Allocate a Package Data Set

If you decide to use a package data set, you must define and allocate it as follows:

Suggested naming conventions:

NODE1

uprfx

NODE2

uqual

NODE3

PACKAGE

Example: Package Data Set Name

uprfx.uqual.PACKAGE

In this example, the following information applies:

Occurrence

One per site.

Format

VSAM

Where defined

In the CA SCM for Mainframe Defaults Table.

Enable Component Validation

The component validation feature is invoked during package CAST, and ensures the following:

An element cannot be moved without its corresponding dependencies.

An element cannot be moved if it has not been assembled, compiled, or linked with the current version of a dependent element.

Note: For more information about enabling component validation, see the Packages Guide.



Approver Groups

Decide who will approve packages in specific inventory areas. Define approver groups for these approvers, and then relate the groups to the necessary inventory areas.

Note: For more information about approver groups, see the Packages Guide.

7-Define Site Level Type Processing Sequence (Optional)

When this optional feature is enabled, API element actions (if wildcarded) and SCL element actions are executed in type sequence order defined in a sequence at the site level by the CA SCM for Mainframe administrator.

By default, CA SCM for Mainframe allows you to define the relative sequence of processing for the various element types defined within a system. If your site does not select the Global Type Sequencing option, element actions execute within your system in the same order as the types were defined to the system and stage by the administrator or as reordered by the administrator using the Type Sequence panel.

To implement Global Type Sequencing, you need to allocate the Parmlib data set and create the Type Sequence member file, and add the two parameters, PARMLIB= and TYPESEQMBR=, to the C1DEFLTS table.

Note: For more information about implementing Global Type Sequencing, see the Administration Guide.

Allocate the Parmlib Data Set

The Parmlib data set is used to contain the Type Sequence member. Allocate the data set by editing the BC1JEPRM member in your site's CA SCM for Mainframe JCLLIB data set, and then execute the batch job.

Create the Type Sequence Member

The order of the type records in the Type Sequence member represents the processing sequence. You can use the standard ISPF editor to create the type sequence file. The build utility JCL member BC1JBTSE in your site's CA SCM for Mainframe JCLLIB data set can build type sequence records for all types defined to a site. Edit the type sequence file, by re-ordering types and deleting types that do not require any particular processing order. Then copy the file to the site's Type Sequence member file within CA SCM for Mainframe's Parmlib data set. Any types not defined in the member are processed after all the defined types are processed.

How to Implement for Output Management


How to Implement for Output Management To successfully implement CA SCM for Mainframe for output management, complete the following steps:

1. Complete all steps to implement CA SCM for Mainframe for source management (see page 103).

2. Define and allocate output libraries (see page 119).

3. Define processors (see page 121).

After you complete these steps, you can continue with the next section, How to Implement CA SCM for Mainframe for Configuration Management (see page 123), or if you are implementing CA SCM for Mainframe for source and output management only, perform the Final Implementation Steps (see page 123).

Define and Allocate Output Libraries

In addition to the libraries allocated when you implemented CA SCM for Mainframe for source management, you must also allocate additional libraries to store the outputs of CA SCM for Mainframe processors. The following information summarizes which user-defined libraries should be allocated to implement CA SCM for Mainframe for output management.

Executable libraries, by type

Source output libraries, by type

Processor load libraries

Include libraries, by type (if applicable)

Listing libraries (if you are storing listings online)

CA SCM for Mainframe can write outputs to any output library. For example, if your site has centralized load libraries or JCL libraries, CA SCM for Mainframe can write to them. The output library naming conventions in this section are suggestions only.

Output Library Naming Conventions

When you define output libraries, use the following conventions:

NODE1

System

NODE2

Stage



NODE3

COPYLIB

LISTINGS

LOADLIB

JCLLIB

MACLIB

OBJLIB

PROCLIB

SRCLIB

and so on

Example: Output Library Name

FINANCE.TEST.LOADLIB

Occurrence

Usually one per system/stage/type.

Size

See the following for size information:

– To estimate the size of these data sets, see The Disk Space Requirements Worksheet.

– For directory sizing and data set maintenance information, see the Utilities Guide.

Format

PDS, PDS/E, CA SCM for Mainframe LIB, CA Panvalet, CA Librarian. Output library format is usually dictated by executable requirements. Source output and INCLUDE libraries can also be HFS directories.

Where defined

In the type definition and in processors.

Output Library Allocation

Consider setting up a worksheet for output library allocation. Use a format similar to the sample worksheet shown below:

Library Name Format DCB Information Size

FINANCE.TEST.-LOADLIB PDS RECFM=U, LRECL=80,… 1 cyl

FINANCE.QA-JCLLIB PDS 1 cyl



Library Name Format DCB Information Size

FINANACE.EMER.-SRCLIB PDS 10 cyl

FINANCE.PROD.-MACLIB PDS 1 cyl

FINANCE.TEST.-JCLLIB PDS 1 cyl

Note: For examples of output library allocations, see the type definitions in the sample application.

Define Processors

Processors are JCL streams that create executables from CA SCM for Mainframe elements. To use CA SCM for Mainframe for output management, you must write and maintain processors to create the desired executables.

Writing Processors

Note: For an explanation and illustration of processor creation, testing, and management, as well as the various types and uses of processors, see the Extended Processors Guide.

If you plan to implement CA SCM for Mainframe for configuration management, be sure to include the MONITOR=COMPONENTS statement in your processors. See the Automated Configuration Option Guide for instructions on adding MONITOR=COMPONENTS to your processors.

Important! You should test your processors thoroughly, using representative examples of each element type of the application to be implemented.

Processor Groups and Types

Using the list of types and processor groups produced by the Inventory Analyzer, define the processor groups and associate them with their respective types.

Note: For more information about processor groups, including naming conventions, see the Extended Processors Guide.

Managing Processors

Note: For more information about managing processors, see the Extended Processors Guide.



Determining Type Processing Sequence

A type processing sequence is used when multiple element types are processed within a single batch request.

By default, in batch and packages, actions are processed in the same order as the types were defined to the system and stage by the administrator or as reordered by the administrator using the Type Sequence panel. However, if the option Global Type Sequencing is enabled at your site, SCL and API element actions execute in type sequence order defined at the site level, regardless of the action's inventory location.

Note: For more information about type sequence definition, see the Administration Guide.

Sample Processors

The sample implementation includes the following processors:

GCOBNBL

A COBOL compile and link-edit processor.

GCIINBL

A COBOL II compile and link-edit processor.

GCOBDBL

A processor that performs a DB2 precompile, compiles and link-edits a COBOL program, binds the DB2 plan, and footprints the plan table.

GCIIDBL

A processor that performs a DB2 precompile, compiles and link-edits a COBOL II program, binds the DB2 plan, and footprints the plan table.

GCOBNBO

A compile-only processor for COBOL.

GCOBNBL1

A COBOL compile and link-edit processor with linkage editor input.

GCOBNCL

A CICS precompile, COBOL compile, and link-edit processor.

GLECNNL

A link-edit-only processor (composite link).

GASMNBL

An assembler compile and link-edit processor.

How to Implement for Configuration Management


How to Implement for Configuration Management To successfully implement CA SCM for Mainframe for configuration management, complete the following steps:

1. Complete all steps to implement CA SCM for Mainframe for source management (see page 103).

2. Complete all steps to implement CA SCM for Mainframe for output management (see page 119).

3. Enable the Automated Configuration Manager (ACM) capability (see page 123).

Enable ACM

If you did not previously enable the Automated Configuration Manager (ACM), do so now by editing the Defaults Table.

Important! The final step in implementing for configuration management is to create the ACM baseline. This must be done after you have loaded your inventory into CA SCM for Mainframe. For more information, see Load the Inventory (see page 124).

How to Finalize the Implementation No matter which level of implementation you have selected, you must perform the following steps to finalize the implementation process:

1. Enable security for CA SCM for Mainframe (see page 123)

2. Load inventory into CA SCM for Mainframe (see page 124)

3. Train (or set up training for) the CA SCM for Mainframe users in your organization (see page 125)

4. Go into production with CA SCM for Mainframe (see page 125)

Enable Security

See the Security Guide for instructions on implementing security for your CA SCM for Mainframe system. We recommend that this be done now rather than earlier, so as not to interfere with the implementation work you have been doing.

Test the security implementation across all functions and user levels, before full implementation, to make sure it works properly.

How to Finalize the Implementation


Load the Inventory

Before loading the entire inventory, verify your implementation using a small subset of the applications to be controlled.

For applications that are actively changing, minimize the change activity to be as close to implementation as possible. You may want to rerun the Inventory Analyzer before implementing CA SCM for Mainframe, to account for any new components.

Load the inventory that you want CA SCM for Mainframe to manage. Run parallel tests for a week or so to make sure the product is functioning correctly, and then reload the inventory.

Note: Using the Load Utility is the easiest way to load the inventory into CA SCM for Mainframe. For more information about the Load Utility, see the Utilities Guide.

Enable the ACM Baseline

If you are implementing CA SCM for Mainframe for configuration management, you should create a baseline component list for those inventory elements that have components.

CA SCM for Mainframe ACM produces component lists when a Generate processor is executed against an element. To make sure that this process does not replace existing load modules, do the following:

Take the Generate processor in production and temporarily change the SYSLMOD or other output library to DUMMY.

Issue a Generate action against all programs or elements that have components.

Change SYSLMOD back to its original value.

Important! If this is a source-management-online implementation, you may have to change your Compile procedures to accommodate storing source under CA SCM for Mainframe. For example, if you have CA Panvalet and have used PAN#1 for retrieval prior to compiling, you may have to change the RETRIEVE action in CA SCM for Mainframe.

How to Finalize the Implementation


Provide Internal Training

Everyone who will be using CA SCM for Mainframe should be trained. Typically, end-user training for use of basic CA SCM for Mainframe functionality should take about two to four hours.

Training can be delivered by CA personnel, through the CA CBT (self-training) courses, or through internal training programs.

You should also consider using the procedures you have documented during the implementation process as the basis for a user's guide for your site.

Go into Production

After initially loading your inventory into CA SCM for Mainframe, run the product in parallel with your production system for a week or so to make sure everything is functioning as designed. You should then be able to go into production.

You should hold a post-implementation review two to four weeks after production cutover. Use the feedback from the review to fine-tune your implementation to better meet the needs of your site.

Frequently Asked Questions 127

Appendix A: Frequently Asked Questions


LMP Key Codes (see page 127) Support Issues (see page 128) New Features (see page 129) ACMROOT, ACMXREF, and the ELEMENT Catalog (see page 129) Package Approval (see page 129) The Display Elements Action (see page 130) Message Severity (see page 130) C1DEFLTS and the Element Catalog (see page 131) Change Order (see page 131) The Element Catalog and Element Registration (see page 132) The ENTERPRISE_PKG=A Field (see page 132) Reassembling Exit Programs (see page 133) API Compatibility (see page 133) The Security Table (see page 133) Long Name Elements (see page 134)

LMP Key Codes Symptom:

Could you please provide a description for the LMP key codes.

Solution:

The following information provides a description for all LMP key codes:

A8

CA SCM for Mainframe Change Manager Parallel Development option

A9

CA SCM for Mainframe Change Manager Extended Processors option

AK

CA SCM for Mainframe Change Manager

AY

CA SCM for Mainframe Change Manager Automated Configuration option

Support Issues


B4

CA SCM for Mainframe Change Manager CA Roscoe Interface

BM

CA SCM for Mainframe Change Manager External Security Interface

BN

CA SCM for Mainframe Change Manager InfoMan Interface

BO

CA SCM for Mainframe Change Manager CA Librarian Interface

BU

CA SCM for Mainframe Change Manager CA Panvalet Interface

BX

CA SCM for Mainframe Change Manager Quick Edit option

CB

CA SCM for Mainframe Footprint Synchronization option

CU

CA SCM for Mainframe Change Manager CA Netman Interface

EN

CA Endevor/DB for CA IDMS

Support Issues Symptom:

How can I open an issue with CA SCM for Mainframe Technical Support without calling the hotline?

Solution:



New Features


New Features Symptom:

Is there a way that I can learn about the new CA SCM for Mainframe features in this release?

Solution:

You can read about the new features in the Release Notes, and you can also display a summary of changes on the New Features panel within the product.

ACMROOT, ACMXREF, and the ELEMENT Catalog Symptom:

Is there a way that ACMROOT, ACMXREF, and ELEMENT Catalog can be controlled by LSERV?

Solution:

We recommend that the Element Catalog be controlled by LSERV. ACMROOT and AMCXREF cannot be controlled by LSERV.

Package Approval Symptom:

In previous releases, there was a PTF O000315 that would bypass approval and package processing. Where can I find this?

Solution:

This optional PTF is now part of the ENCOPTBL (Optional PTF Table). You can find this PTF in the table using the command line and by typing f'315/' and pressing Enter. There are two parts of this PTF. Read them carefully. After you have updated the table, you need to reassemble and relink, and if applicable, refresh the linklist.

The Display Elements Action


The Display Elements Action Symptom:

When I use the DISPLAY element action with CCID=, LIST=Y, and the SYSTEM and SUBSYSTEM left blank or wildcarded with an asterisk (*), I am prompted to select a system and subsystem. How can I display the list and include all systems and subsystems?

Solution:

By default, CA SCM for Mainframe prompts you to select a specific system and subsystem combination before building an Element Selection list. To bypass this requirement, activate an option in the ENCOPTBL (Optional Features Table) for optional PTF O002553. The ENCOPTBL can be found in the iprfx.iqual.TABLES library that is delivered with the product. To enable this option, you must uncomment the line ENHOPT NO_SYS_SBS_SELECTION_LIST=ON, reassemble and re-link the ENCOPTBL. To find this optional PTF in the table on the command line type F 'O002553' and press Enter.

Message Severity Symptom:

In previous releases of the product, I was able to change the severity of messages generated by CA SCM for Mainframe with Optional PTFS. For example, IMGR009E, SMGR116E, and C1G0507E. Where can I find these PTFS in the new release?

Solution:

The PTFS for these messages have been incorporated into the Optional PTF Table (ENCOPTBL). This member can be found in the iprfx.iqual.TABLES library delivered with the product.

C1DEFLTS and the Element Catalog


C1DEFLTS and the Element Catalog Symptom:

If I add a new environment to my C1DEFLTS Table and I'm using the Element Catalog, how can I activate this environment?

Solution:

You do not need to do anything. The first time that CA SCM for Mainframe is invoked after you have added the environment to the C1DEFLTS Table, the MCFs will be updated with the Element Catalog name in the stage record. From that point on, the product will check to ensure that the catalog name in the MCF and the C1DEFLTS are the same. If the names are not the same, the MCF open will fail. This check has been added to prevent MCFs from belonging to more than one catalog.

Change Order Symptom:

How can I ensure that all of my changes will be added in the correct order? For example, how can I ensure that my copybooks are added before my source program?

Solution:

If you are performing your actions in the foreground, the order depends on you. You have to ensure you add all your copybooks first, then your subroutines, and finally your main program. In batch and in packages, CA SCM for Mainframe follows the type sequence defined to each system/stage as established by your CA SCM for Mainframe Administrator. By default, the type sequence is defined in numerical order based on the order in which the types were defined to the product. The first type to be defined is placed at the top of the list; the last type to be defined is placed at the bottom of the list. The CA SCM for Mainframe Administrator can adjust the numerical assignments on the Type Sequence panel. In addition, you can use the Global Type Sequence option to process element actions by type sequence regardless of the inventory location of each action. Using Global Type Sequencing, SCL and API element actions are executed in type sequence order defined at the site level in the Type Sequence member created by the administrator.

Note: For more information about how type sequencing works, see the SCL Reference Guide. For more information about adjusting the Type Sequence order and the Global Type Sequencing option, see the Administration Guide.

The Element Catalog and Element Registration


The Element Catalog and Element Registration Symptom:

I don't understand the difference between the Element Catalog and Element Registration. Are they the same thing?

Solution:

No, the Element Catalog and Element Registration are not the same thing and they are not related. Element Registration is an optional feature of CA SCM for Mainframe that enables you to choose whether you want to restrict the use of the same element name at the subsystem or processor group level. The Element Catalog, which is required when upgrading to r7 and greater, is a VSAM file that allows CA SCM for Mainframe to support long element names (HFS/UNIX).

The ENTERPRISE_PKG=A Field Symptom:

I have upgraded from CA SCM for Mainframe release 3.8 and I don't understand what ENTERPRISE_PKG=A means in the ENDICNFG Table.

Solution:

This field will be used by CA CM Enterprise Workbench. In the ENDICNFG table, which is located in the iprfx.iqual.TABLES library delivered with CA SCM for Mainframe, the option ENTERPRISE_PKG= has three possible values:

A

List all packages (Enterprise and CA SCM for Mainframe)

E

List Enterprise packages only

X

Exclude Enterprise packages from the list

Reassembling Exit Programs


Reassembling Exit Programs Symptom:

Do I need to reassemble my Exit programs written for earlier releases of the product?

Solution:

Yes, we recommend that all programs always be reassembled using the macros in the current release.

API Compatibility Symptom:

Is the API upwardly compatible?

Solution:

Beginning with r7, API programs are upwardly compatible. You do not have to reassemble or compile your existing API programs, unless you want to take advantage of the new fields that were added to a request or response structures.

The Security Table Symptom:

I have upgraded from CA SCM for Mainframe release 3.7.2. Do I need to make any changes to my security table?

Solution:

The tables format1, format2, format3, format4, and format5 have changed. For more information about the changes you need to make to the security tables, see the Security Guide.

Long Name Elements


Long Name Elements Symptom:

Is CA CM Enterprise Workbench required for long name elements?

Solution:

Yes. USS long file names can be maintained using SCL. CA CM Enterprise Workbench is required for online list, display, and action processing.

Statement of Integrity 135

Appendix B: Statement of Integrity


CA Software Change Manager for Mainframe Statement of System Integrity (see page 135)

CA Software Change Manager for Mainframe Statement of System Integrity

Preserving the integrity of the operating system environment has always been a fundamental requirement of CA SCM for Mainframe and family of products. Most of the CA SCM for Mainframe and family of products, which are designed for end user operation, require no authorization to function properly. The few end user components, which do require APF authorization, were designed to perform their authorized functions sealed within the boundaries of the CA SCM for Mainframe system architecture. Several system-oriented components of CA SCM for Mainframe and family of products also require APF authorization. These functions have been designed to use system keys and supervisor states only when necessary.

There are no known exposures introduced within the operating system when installing CA SCM for Mainframe and family of products under a supported release of z/OS. This statement assumes that the installation of CA SCM for Mainframe and family of products is in accordance with the procedures and practices recommended by CA and set forth in the applicable guide.

The CA SCM for Mainframe and family of products programs are in full compliance with the requirements for maintaining operating system integrity as defined in the manual z/OS MVS Programming: Authorized Assembler Services Guide (SA22-7608), specifically preventing:

Any circumvention or disabling of store or fetch protection.

Any bypass of OS password or RACF controls.

Any program from obtaining control in a lower key or acquiring APF authorization.

CA will provide remedial support for problems where the proper installation of an unaltered copy of CA SCM for Mainframe and family of products introduces an integrity exposure in a release of z/OS currently supported by IBM. CA reserves the right to provide problem fixes only for product releases that are currently supported by CA.

Glossary 137

Glossary

Access Security Table The Access Security Table defines the environments to which users have access. Each site has one Access Security Table.

action An action is a command to manage elements.

Add Elements Action The Add Elements Action places members from an external data set under control of CA SCM for Mainframe.

alternate ID An alternate ID is a facility that protects the data sets controlled by CA SCM for Mainframe (such as the Master Control Files, package data sets, and base and delta libraries) from access by users, while still allowing CA SCM for Mainframe to have access.

approval An approval is the electronic signoff mechanism for packages. An approval may be required for a package before execution.

approved The approved status is assigned after the required approvers have reviewed, signed off, and approved a package.

approver An approver is a person authorized to sign off on a package, before execution. Signing off on a package involves reviewing the information in the package and approving or denying the package.

approver group An approver group is a collection of one or more approvers. An approver group is defined within each environment and can be associated with inventory areas.

approver group relationship An approver group relationship is established between an approver group and one or more inventory areas, authorizing members of the approver group to review (and then approve or deny) packages related to the inventory areas.


approver type An approver type is the specification of the kinds of packages that an approver group can review. When the approver type is Standard, the approver group can review only standard packages related to its authorized inventory areas. When the approver type is Emergency, the approver group can review only emergency packages related to its authorized inventory areas.

Archive Elements Action The Archive Elements Action writes an element and all related CA SCM for Mainframe information to a sequential data set.

authorization An authorization is the ability to perform certain privileged functions within the IBM z/OS environment.

Automated Configuration Manager (ACM) The Automated Configuration Manager (ACM) is an optional facility that allows you to monitor selected libraries and data sets and maintain a component list for each element in the monitored areas. The component list provides an audit trail of program-component information at the time of each compilation.

backin The backin command restores the executable members of a package to the state they were in before the package was backed out. A backin will also reverse the backout process.

backout The backout command returns the executable members of a package to the state they were in before package execution.

base level The base level is the lowest level of an element within a particular stage when storing elements with forward deltas. This level represents the source for the element in that stage. If an element exists in both stages, there is a base level in each stage. When storing elements with reverse deltas, the base level is the current level.

base library The base library is a partitioned data set (PDS), a CA Panvalet, a CA Librarian, or ELIB file that stores the base members for elements defined to CA SCM for Mainframe. A base library is defined for each element type, but it can be shared across types.

base member The base member is a located in a base library. Each base member corresponds to an element, and contains the source for the base level of the element. Base member names are generated internally by CA SCM for Mainframe, and do not correspond to the element name unless you use reverse delta with non-encryption.

Glossary 139

base regression The base regression is the percent by which the statements stored in a new level of an element change the statements stored in the base level.

batch A batch is an IBM term referring to an environment in which noninteractive programs are executed. In CA SCM for Mainframe, batch refers to the execution of actions and reports in a noninteractive region, as opposed to execution in the foreground.

browse The browse command lets you view the content of a data set without being able to change the contents.

Bulk Data Transfer (BDT) The Bulk Data Transfer (BDT) is an IBM transmission utility supported by the CA SCM for Mainframe package shipment utility. BDT is abbreviated as BDT2 for BDT version 2 and BDTN for BDT with NJE/NJI.

C1DEFLTS Table The C1DEFLTS Table is the CA SCM for Mainframe Defaults Table.

cast a package The cast a package command freezes the actions included in the package. After a package is cast, it cannot be edited and only approvers can work with it.

CCID definition data set The CCID definition data set identifies the CCIDs to be used within CA SCM for Mainframe. The definition file must be a card-image data set (80-byte, fixed-format records).

CCID validation The CCID validation checks a CCID specified on an action against the CCIDs defined in the CCID definition data set.

Change Control ID (CCID) A Change Control ID (CCID) is a logical grouping mechanism by which user-specified portions of the CA SCM for Mainframe inventory can be tagged, and then viewed, tracked, and manipulated. CCIDs are optional but may be required on a system-by-system basis. The same is true of comments.

change regression The change regression is the percent by which the statements stored in a new level change the revisions made by the previous level.

checksum The checksum is an internally calculated value within a package. CA SCM for Mainframe uses the checksum to determine if a package has been changed.


Classification Classification is the system, subsystem, and type associated with an element.

command field The command field appears on the second line of panels in which you can specify a TSO command. You can enter any appropriate TSO command in the command field.

comment A comment is a user-defined remark (up to 40 characters) associated with an action or package. A comment is used with CCIDs, and generally describes the reason for the action or purpose of the package.

commit a package The commit a package command records all events related to a package, and removes all backin and backout information. After a package is committed, the package can no longer be backed out or backed in.

committed The committed status appears after a package has been committed.

complementary data sets Complementary data sets can be shipped along with package shipments. The complementary data sets for a shipment contain a backout of the shipment.

component A component (primarily for CA SCM for Mainframe ACM) is the output produced or the input read in by a generate or move processor. The components of a generated element include the input components that were included to produce an output of the generate processor, the element itself, all outputs created by the generate or move processor, and user-defined data. Components are referenced by element or member names.

component list A component list is a list of all components created or read by a generate or move processor. The component list can be viewed using the Print Elements action, or the Display Element/Component panel (CA SCM for Mainframe ACM). The component list provides an audit trail of program-component information at the time of each compilation.

component monitoring Component monitoring is a feature of CA SCM for Mainframe ACM that allows you to check selected data sets for component relationships.

component validation Component validation occurs when a package is cast. CA SCM for Mainframe then validates that all dependent components are in the package and that those components have not changed since they were last used.

Glossary 141

concurrent action processing Concurrent Action Processing executes the following element actions concurrently: ADD, UPDATE, RETRIEVE, MOVE, GENERATE, DELETE, SIGNIN, and TRANSFER CA SCM for Mainframe to CA SCM for Mainframe, which reduces the elapsed time it takes to process multiple actions.

configuration management Configuration management is the capture and storage of program-component relationships and the tracking of these relationships over time.

CONNECT:Direct CONNECT:Direct is a network transmission utility provided by Sterling Commerce and supported by the CA SCM for Mainframe package shipment utility. It is abbreviated as NWD when establishing destinations. CONNECT:Direct was formerly known as Network DataMover.

consolidation A consolidation is a CA SCM for Mainframe facility that allows you to specify a number of delta levels to retain when a member reaches the consolidation level specified for its type. If you do not specify the number of levels to retain, CA SCM for Mainframe consolidates all levels.

control section (CSECT) The control section (CSECT) is an IBM term for the part of a program that is a relocatable unit and for which all components are loaded into adjoining main storage locations.

Copy Elements Action The Copy Elements Action copies an element from an archive data set to a data set external to CA SCM for Mainframe.

copyback A copyback (also known as fetch) searches for an element along the map (beginning at a designated stage), finds the element, and then copies it back to the initial stage. Copyback is available as an explicit option with the Generate Elements action. Copyback is also used when adding, transferring, and moving elements.

create a package Create a package is performed to build the SCL for a package, and then associate the SCL with other package-related information such as a package ID, an execution window, and so forth.

CSECT (control section) The control section (CSECT) is an IBM term for the part of a program that is a relocatable unit and for which all components are loaded into adjoining main storage locations.


current level The current level is the most recent source for an element. When using forward deltas, the current level of an element comprises the base level plus all subsequent change levels. When using reverse deltas, the current level of an element is the current source.

data set name (DSN) The data set name (DSN) is the data set name for the SCL.

data set validation Data set validation is an optional feature to verify that retrieved elements are added or updated from the data set to which they were last retrieved. This ensures that the same copy of the element (revised as appropriate) is placed back in CA SCM for Mainframe. Data set validation can be specified separately by system. If this facility is in effect for a system, you can override it to add the element back from a different data set if you have proper authority.

default A default value is the value that CA SCM for Mainframe assumes to be in a field or statement if you do not provide an alternative value. On foreground panels, fields usually display default values.

Defaults Table The Defaults Table (also known as C1DEFLTS) is a table of site-specific information necessary for CA SCM for Mainframe operation. The Defaults Table includes environment and stage definitions, installed options, and site-specific hardware settings. There is only one Defaults Table for each site.

defaults table The defaults table is a reference to C1DEFLTS, also known as the CA SCM for Mainframe Defaults Table.

Delete Elements Action The Delete Elements Action erases base and delta forms of an element and removes element information from a Master Control File (MCF) or a component list.

delete processor A delete processor is a processor that is run when an element is deleted from a stage. Typically, the delete processor deletes the output created by the corresponding generate processor.

delta level A delta level is a record of a change to the base level of an element. Each change to an element creates a delta level. CA SCM for Mainframe compares the current level to the new source and builds a delta level containing the changes to the source.

Glossary 143

delta library A delta library is a partitioned data set (PDS), a CA Panvalet, a CA Librarian, or a ELIB file that stores the delta members for elements defined to CA SCM for Mainframe. A delta library is defined for each element type.

delta member A delta member is a member in a delta library. Each delta member corresponds to an element, and contains all the levels for that element subsequent to the base level. Delta member names are generated internally by CA SCM for Mainframe and do not correspond to the element name, unless reverse deltas are used.

denied A denied status of a package appears when the package has been reviewed, but denied, by an approver.

deny a package The deny a package command is an option for a package approver. If one approver denies a package, it cannot be executed.

destination A destination is where package outputs are shipped. A destination record contains the information needed by CA SCM for Mainframe to ship package outputs to the destination.

Display Elements Action The Display Elements Action is used to view environment definitions, element information, and footprint-related data.

DSN (data set name) The data set name (DSN) is the data set name for the SCL.

DSN mapping rule A DSN mapping rule is a user-defined correspondence between host and remote data set names. DSN mapping rules are used when shipping package outputs.

element An element is a partitioned data set (PDS) member, a CA Panvalet, CA Librarian, or sequential data set that has been placed under control of CA SCM for Mainframe. The default element name is the member name.

element change The element change is a view of element information that shows the current level of an element, annotated to indicate the level at which each line was added to the source.


element component The element component is the part of a component list referred to as element information. This information includes the footprint of the CA SCM for Mainframe source.

element history The element history is a view of element information that shows all lines that have been present in a piece of source code, annotated to show the level at which the line was added, deleted, or both from source.

element master The element master is a view of Master Control File (MCF) information about an element.

element name The element name is the name assigned to an element, used to identify the element within CA SCM for Mainframe. We recommend that any outputs created by output management be assigned the name of the corresponding element. Element names must be unique within each system, subsystem, and type combination.

element summary of levels The element summary of levels is a summary view of activity against an element at all levels. Information provided includes the number of statements at each level, the number of lines added, and the number of lines deleted.

ELIB ELIB is a high-performance alternative to OS-partitioned data sets under CA SCM for Mainframe. ELIB data sets may reorganize member space automatically as members are rewritten or deleted, exploit 31-bit storage for VSAM-organized data sets, expand directories and data sets automatically, provide improved directory processing, and maintain additional statistical information about member size.

emergency approval Emergency approval is assigned to emergency packages. An approver group must be assigned the authority to approve emergency packages.

emergency package An emergency package is one of two types of packages (either standard or emergency when created). Emergency packages require approval from emergency approver groups.

enable backout The enable backout option appears when creating a package. You can decide whether or not to allow the package to be backed out.

Glossary 145

environment An environment is the top level of the logical structure used to classify elements in CA SCM for Mainframe. Environments usually correspond to functional levels in an organization (for example, development, quality assurance, and production). Each environment has two stages. There is no limit to the number of environments you can use.

environment name The environment name is a name to identify each environment within CA SCM for Mainframe. The name can be up to eight characters, and include any of the following: A-Z, 0-9, @, #, and $.

environment title The environment title is a descriptive title assigned to each environment that is used in various displays and reports (up to 40 characters).

ESI (External Security Interface) The External Security Interface (ESI) is an optional interface used to implement external security at your site. When installed, this interface replaces the native security facility supplied on the installation cartridge (and implemented through the security tables), with calls to RACF, CA ACF2, or CA Top Secret. It is also known as the CA SCM for Mainframe Change Manager Interface for External Security.

execute a package The execute a package command runs a package. Packages that execute successfully can be backed out or committed.

Execution Report The Execution Report is output when you run CA SCM for Mainframe actions. The Execution Report documents the actions requested and the processing that occurred. The report can be viewed online by browsing data sets userid.C1TEMPR1.MSGS or userid.C1TEMPR2.MSGS. CA SCM for Mainframe prints the report as member C1MSGS1 on the batch SYSOUT.

execution window The execution window is a timeframe (start and end date) within which a package must be executed.

exit An exit is part of the CA SCM for Mainframe exit interface designed for use with exits written in either assembler or in high-level languages such as COBOL.

export a package The export a package command copies package SCL into an external data set.


External Security Interface (ESI) The External Security Interface (ESI) is an optional interface used to implement external security at your site. When installed, this interface replaces the native security facility supplied on the installation cartridge (and implemented through the security tables), with calls to RACF, CA ACF2, or CA Top Secret. It is also known as the CA SCM for Mainframe Interface for External Security.

footprint A footprint is encrypted data added by processors to individual source, object, or load modules, to identify the CA SCM for Mainframe element associated with the module. CA SCM for Mainframe uses the data to display and process information for the element. A footprint includes the site ID, environment name, stage number, system name, subsystem name, element name, element type, element version or level, and the date and time the footprint was assigned, all in encrypted format.

foreground The foreground is an IBM term referring to an environment in which interactive programs are executed. In CA SCM for Mainframe, you run actions in the foreground by requesting those actions through the CA SCM for Mainframe Foreground Options Menu.

forward delta Forward delta is a method for recording changes that stores a base version of code, and then builds current versions by applying changes made to the base.

forward recovery Forward recovery is the process of taking an old level of an element and making it the current one (new level). As a result, any changes made by the levels between are backed out. To perform forward recovery, you first retrieve the older (to-be-recovered) level, and then add or update the element using the retrieved source to create the new level.

Generate Elements Action The Generate Elements Action translates source into executables, and then populates output libraries with the executables by executing the generate processor for an element.

generate processor A generate processor translates source into executables, and then populates output libraries with these executables.

Glossary 147

group name A group name is a name associated with a security configuration that applies for multiple users, found within the definition of the Access and User Security Tables. The name is then associated with any number of specific user IDs, to associate the IDs with the group-level security. This is a convenient way to assign security to several users having identical levels of access to the CA SCM for Mainframe environment.

identify record (IDR) An identify record (IDR) is an IBM term for a record in a load module that contains user-defined data. An IDR is created by the linkage editor when it encounters an IDENTIFY statement in the object deck. Within CA SCM for Mainframe, IDRs are used to store the footprints associated with load modules.

IDR (identify record) An identify record (IDR) is an IBM term for a record in a load module that contains user-defined data. An IDR is created by the linkage editor when it encounters an IDENTIFY statement in the object deck. Within CA SCM for Mainframe, IDRs are used to store the footprints associated with load modules.

image An image is the current level of an element, when the element is stored in reverse delta format, using non-encryption.

image library An image library is a library that contains elements stored in reverse delta format, using non-encryption.

import a package The import a package command is used to create a package by copying SCL from an external data set.

INCLUDE library An INCLUDE library is a CA Panvalet library, CA Librarian library, or partitioned data set (PDS) that contains INCLUDE members referenced within CA SCM for Mainframe elements. This library is optional and it can be defined for each element type. The INCLUDE library is used by Retrieve Elements actions if you specify that you want to expand INCLUDEs at the time the element is retrieved. It is also used by the CONWRITE utility, if you specify that you want to expand INCLUDEs during CONWRITE processing.

input component An input component is an included component to produce an output when executing the generate or move processor when using CA SCM for Mainframe ACM. For example, a copybook is the input component when compiling a COBOL program.


inventory An inventory contains the software components that make up your application software systems.

Inventory Analyzer The Inventory Analyzer is a CA product that allows you to analyze your software inventory, classifying it according to CA SCM for Mainframe types. This product is used when implementing CA SCM for Mainframe.

inventory area The inventory area is a subset of a software inventory, defined by its CA SCM for Mainframe location (environment and stage) and classification (system, subsystem, and type).

jump A jump moves an element from stage 2 in one environment to a stage in another environment on a map route, when a version of the element exists at an intermediate stage that is not part of the map route.

last action The last action is the most recent action executed for an element. Once executed, each action is recorded as the last action except Archive, Delete, Display, List, and Print.

last action CCID The last action CCID is the CCID specified for the last action executed against an element.

level A level is the source for an element at a particular time. When an element is first added to a stage, there is one level (known as the base level). Each time CA SCM for Mainframe actions change the source thereafter, a new delta level is created.

level number The level number is an identifier for a specific level of an element. CA SCM for Mainframe assigns each set of changes a level number that is one higher than the number assigned to the preceding level.

library management Library management is the classification, control, and storage of the physical components of a software inventory.

List Elements Action The List Elements Action lists elements from a Master Control File (MCF) or archive data set in the form of action requests or members from a library. This action can also be used for text scanning. If the Automated Configuration Manager facility is installed, this action can also search a component list based on specified criteria.

Glossary 149

List Panel The List Panel is used by CA SCM for Mainframe to display lists of systems, subsystems, types, elements, or members, and also to display selection options for users. List panels are prepared and processed by the ISPF Table Display Facility.

Listing libraries Listing libraries are libraries used to store compressed compiler listings produced by processors.

load utility The load utility is a CA SCM for Mainframe utility that is used to load members from an external data set into any stage in an environment.

Location The location refers to the stage and environment where an element resides.

map A map is the promotion routes established for software inventory at a site. Environments and stages are mapped to each other in the CA SCM for Mainframe Defaults Table. Systems, subsystems, types, and processor groups are mapped to each other on their respective definition panels.

Master Control File (MCF) The Master Control File (MCF) is a CA SCM for Mainframe file that contains the definitions of stages, systems, subsystems, element types, and elements. This file is accessed and updated by CA SCM for Mainframe to manage the element definitions, to execute processors, and for other miscellaneous functions. There are two Master Control Files (MCFs) for each environment—one per stage.

MAXRC The MAXRC is a processor keyword that defines the highest acceptable return code for a processor step. If a step exceeds this return code, the CA SCM for Mainframe return code (NDVR RC) is set to 12. When this happens, the Element Master display shows *FAILED* in the NDVR RC field.

MCF (Master Control File) The Master Control File (MCF) is a CA SCM for Mainframe file that contains the definitions of stages, systems, subsystems, element types, and elements. This file is accessed and updated by CA SCM for Mainframe to manage the element definitions, to execute processors, and for other miscellaneous functions. There are two Master Control Files (MCFs) for each environment—one per stage.

model transmission control statements Model transmission control statements control the functioning of data transmission programs used by the package shipment utility.


Move Elements Action The Move Elements Action moves elements between stages, within or across environments.

move processor Move processors copy outputs, element information, and component lists from the source location to the target location of a Move or, optionally, a Transfer action.

name mask A name mask enables you to use the asterisk (*) wildcard character and percent sign (%) placeholder characters when performing actions. Use the wildcard character to specify all names or all names beginning with a particular search string. Use the placeholder character to define a specific position within the search string. For example, the search string UPD% would return four character names beginning with UPD.

native security The native security is an option supplied with the CA SCM for Mainframe installation cartridge.

NDVR RC (return code) The return code (NDVR RC) results from action processing. Values can be 00, 04, 08, 12, and 16.

notification facility The notification facility is a CA SCM for Mainframe facility that allows you to notify users of events that require a response from them.

output component An output component is created as a result of executing the generate or move processor when using CA SCM for Mainframe ACM. For example, an object deck is an output component when compiling a COBOL program.

output library An output library is any of several libraries used during output management, including the CA SCM for Mainframe processor listing library, processor load library, and source output library as well as user copy libraries, load libraries, listing libraries, macro libraries, JCL libraries, databases, and so forth.

output management Output management is an aspect of CA SCM for Mainframe that handles the creation and maintenance of various outputs that relate to an element. The exact nature of these outputs varies depending on the corresponding element type, and is defined by the output management for that type.

Glossary 151

package A package is a group of CA SCM for Mainframe actions that requires approval before it can be executed. Creating packages allows you to group specific actions so they can be maintained and tracked as a single unit, establish formal approval procedures to ensure data integrity through modifications, and centralize specific action groups so you can see them across environments and reuse them.

package data set A package data set is where packages are stored. There is one package data set for an environment.

package events The package events are an audit trail recording the events that have occurred involving a package, logged by user ID, date, and time. Package events relate to the various steps of the package processing procedure, and include Created, Last Updated, Cast, Approved, Executed, Backed Out, Backed In, and Committed.

package exits A package exit is called before, after (or both) package functions and subfunctions.

package shipment A package shipment is the transmission of package outputs, and optionally their backouts, from host sites to remote sites.

package status A package status indicates the status of a package at any specific time. Status levels for packages include In-edit, In-approval, Denied, Approved, In-execution, Executed, Exec-failed, and Committed.

Parallel Development Manager (PDM) Parallel Development Manager (PDM) is a CA product that automatically compares and integrates three versions of source code, allowing you to resolve conflicts resulting from concurrent development or from applying vendor updates to applications that have been customized in-house. Also known as the CA SCM for Mainframe Change Manager Parallel Development Option.

partitioned data set (PDS) A partitioned data set (PDS) is a data set in direct access storage that is divided into partitions, called members. Each member can contain a program, part of a program, or data.

PDS (partitioned data set) A partitioned data set (PDS) is a data set in direct access storage that is divided into partitions, called members. Each member can contain a program, part of a program, or data.


Print Elements Action The Print Elements Action prints element or member information.

PROC RC (processor return code)

The processor return code (PROC RC) is the highest return code from the execution of a processor. This returns code is set to *FAILED* if the return code for any step in a processor exceeds the MAXRC for the processor. This return code is set to *PROC'D?* if the element has not been generated after being restored or transferred from an archive data set or added or updated.

PROC statement A PROC statement is a job control statement used in catalogued or in-stream procedures. PROC statements can be used to assign default values to symbolic parameters contained in a procedure. A PROC statement is also used to mark the beginning of in-stream procedures.

processor component A processor component is the part of a component list that includes processor information when using CA SCM for Mainframe ACM. This information includes the footprint of the processor.

processor group A processor group identifies a set of processors for a specific element type, as well as the default symbolic overrides for the processors' JCL. A group can include up to three processors (one generate, one delete, and one move processor, or any combination). Processor groups are useful when elements of one type require slightly different processing. When you define a type to CA SCM for Mainframe, you can also identify a default processor group for that type. Using symbolics when writing the processors for the default processor group can allow you to use the same processors, by changing symbolic definitions, for other processor groups associated with this type.

processor group symbolics Processor group symbolics are defined in PROC statements in one or more processors in a processor group. The symbolics and their default values appear on the Processor Group Symbolics panel. By modifying the default values, you can use one processor in more than one processor group.

processor listing library The processor listing library is an optional library that stores the listings output from the processor named GPPROCSS.

processor load library The processor load library is a CA SCM for Mainframe library that contains the load-module form of each processor. The modules from this library are executed when processors are invoked.

Glossary 153

processor output library The processor output library is a library (referred to in a processor) to which the processor writes output. Processor output libraries can be source libraries, executable libraries, or listing libraries.

processor return code (PROC RC) The processor return code (PROC RC) is the highest return code from the execution of a processor. This returns code is set to *FAILED* if the return code for any step in a processor exceeds the MAXRC for the processor. This return code is set to *PROC'D?* if the element has not been generated after being restored or transferred from an archive data set or added or updated.

processors A processor is a standard OS JCL job stream that manipulates elements and their outputs. There are generate, delete, and move processors. CA SCM for Mainframe supports both CA SCM for Mainframe symbolics and user-defined symbolics in processors. This capability allows you to write one processor that you can use in multiple processor groups by changing the values assigned to one or more symbolics. CA SCM for Mainframe also provides a set of utilities for use when writing processors, and supports the use of in-stream data in processors.

production data set The production data set is used to store production code. This term is used in the package shipment utility to refer to host and remote production data sets.

program pathing Program pathing is a security option under RACF, CA ACF2, and CA Top Secret, that allows you to restrict the data sets available to particular users, as well as the programs and load libraries from which those data sets can be accessed. This is not a CA SCM for Mainframe option, but is specific to RACF, CA ACF2, and CA Top Secret.

promote The promote action is used to move an element from one inventory area to another inventory area.

promotion management Promotion management is the task of coordinating and validating successive changes to the various inventory areas in a software development setting.

promotion package A promotion package is a type of package that includes move actions only and the from environment and stage location for all the move actions is the same.

quorum A quorum is the minimum number of approvers for which approval is required to execute a package. When a quorum size is specified, at least that many approvers must review and approve a package.


regression Regression refers to the condition where one set of changes to element source is overwritten by a subsequent set of changes. CA SCM for Mainframe flags regression when the changes stored for a specific level of an element overwrite more than a predefined percentage of the element statements.

regression percent The regression percent is the percent of acceptable change to element source, defined for each element type. When this percent is exceeded, the result is a user-specifiable CA SCM for Mainframe return code (0, 4, 8, or 12). Each time a new level is created for an element, CA SCM for Mainframe checks the changes stored in that level against this percent, changes to both the statements stored for the base level (known as base regression) and changes to the statements stored for the previous level (known as change regression). If the amount of change in either case exceeds the defined percent, CA SCM for Mainframe issues a message of user-defined severity.

Reload Utility The Reload Utility allows you to recover a CA SCM for Mainframe VSAM control file (Master Control File, package data set) or a base or delta data set that was lost because of a physical device failure or site disaster. The RELOAD action restores data from data sets created by the unload process.

remote footprint synchronization Remote footprint synchronization is a procedure in which footprinted executables are shipped from a remote site to a host site, where footprint reports are run to compare the executables' footprints with host Master Control File (MCF) information.

remote nodename A remote nodename is part of a package shipment destination that identifies the site to which package outputs are to be shipped. The name must be valid for the selected data transmission program.

request data set A request data set contains action requests to be submitted for batch processing. You create request data sets in foreground using the SCL Generation facility.

request for data The request for data is a package exit capability allowing package exit programs to make multiple, successive requests for CA SCM for Mainframe information on a single invocation of the exit.

reset a package The reset a package action erases all package event records, returning the package to In-edit status.

Glossary 155

Resource Security Table The Resource Security Table defines the element names that are restricted to a particular system and subsystem, within a specific environment. The Resource Security Table is defined by the CA SCM for Mainframe administrator using the CONSDEF macro. Each CA SCM for Mainframe environment can contain, at most, one Resource Security Table.

Restore Elements Action The Restore Elements Action restores an element to CA SCM for Mainframe from an archive data set.

Retrieve Elements Action The Retrieve Elements Action copies any level of an element to an external data set.

Return code (NDVR RC) The return code (NDVR RC) results from action processing. Values can be 00, 04, 08, 12, and 16.

reverse delta The reverse delta is a method for recording changes that stores the most recent version of the code, rebuilding prior versions by backing out individual changes from the current version.

review a package A review a package is performed to review the contents of the package. After reviewing a package, an approver approves it or denies it.

route A route is a series of environment and stage locations that make up the stages in a software life cycle. Working together, all the routes at a site constitute the map for that site.

SCL (Software Control Language) Software Control Language (SCL) is the CA SCM for Mainframe language that is used in batch processing to maintain or act against elements within CA SCM for Mainframe.

security Security is a CA SCM for Mainframe feature that allows you to restrict action requests and access to elements. The security system supplied with CA SCM for Mainframe (known as native security) is implemented using three tables.

sharable A sharable package can be edited by users who did not create the package.

ship utility The ship utility is a CA SCM for Mainframe utility that allows you to ship package outputs to remote sites.


shipment confirmation Shipment confirmation occurs in a package shipment after executing the data transmission utility and after executing the remote copy or delete job step.

shipment staging Shipment staging is the creation and population of host staging data sets with package outputs or backout members.

Signin Elements Action The Signin Elements Action removes the current signout for an element. Signin can be implicit or explicit.

signout A signout is the assignment of a user ID to an element, establishing ownership of the element. Signout is automatic when adding or updating elements in or when retrieving elements from CA SCM for Mainframe.

site The site is the location at which CA SCM for Mainframe is installed. The site is defined in the CA SCM for Mainframe Defaults Table, where it is assigned a site ID.

SMF (System Management Facilities) System Management Facilities (SMF) is IBM’s SMF.

Software Control Language (SCL) Software Control Language (SCL) is the CA SCM for Mainframe language that is used in batch processing to maintain or act against elements within CA SCM for Mainframe.

software distribution Software distribution is the automated distribution and synchronization of software changes and the tracking of the implementation of the changes.

software life cycle The software life cycle defines the stages through which software passes at a site during development and maintenance. A software life cycle may consist of development, testing, quality assurance, and production.

software management Software management is the process of tracking changes to software components and their interrelationships over time. This process includes configuration management, library management, software distribution, and version control.

source The source is the non-executable form of an element.

Glossary 157

source library A source library is any of several libraries used during source management, including CA SCM for Mainframe base libraries, delta libraries, and INCLUDE libraries.

source management Source management is the aspect of CA SCM for Mainframe that deals with the creation and maintenance of element source. Element source is maintained in base and delta libraries in an internal format or in standard IBM format (if reverse deltas and non-encryption are selected).

source output library A source output library is a CA SCM for Mainframe library that contains the latest full source version of each element. This library is designed for use with copybooks, macros, procedures, and so forth that are copied to other places. This is an optional library. However, if used, it is specified in the definition of the corresponding element type.

stage A stage is a step in the software life cycle. There are two stages defined for each CA SCM for Mainframe environment.

stage ID The stage ID is an identifier for the stage that is used when processing an element action to select (identify) the stage you want to process.

stage name The stage name is assigned to each stage during CA SCM for Mainframe installation. A stage name can include any of the following characters: A-Z, 0-9, @, #, and $.

stage number The stage number (either 1 or 2) is the relative number for the stage within the environment.

stage title The stage title (up to 20 characters) is assigned to each stage and is used in displays and reports to describe the stage.

standard approval A standard approval is one of two types of package approval. Standard packages can be approved only by standard approver groups.

standard package A standard package is one of two types of packages (standard or emergency). Standard packages require approval from standard approver groups.


subsystem A subsystem is a part of the CA SCM for Mainframe classification of an element. Subsystems are used for specific applications within a system. For example, you may have a purchase order and accounts payable subsystem within the financial system.

symbolic A symbolic is used by CA SCM for Mainframe processors to represent a value specific to an individual run of a processor. CA SCM for Mainframe supports two kinds of symbolics (CA SCM for Mainframe symbolics and user symbolics). CA SCM for Mainframe symbolics (preceded by &C1) are used in CA SCM for Mainframe processors to represent a value specific to an individual run of the processor. Values are assigned to CA SCM for Mainframe symbolics when the processor is executed. User symbolics are defined by users in JCL PROC statements in processors. You can use one processor in multiple processor groups.

synchronize A synchronize conflict is detected when transferring or moving an element with history, if the current level of the target does not match any level of the source. CA SCM for Mainframe searches for the level of the target to match a level of the source, and this level becomes the synchronization level. When there is a synchronization conflict, CA SCM for Mainframe does not allow the element to be transferred or moved unless the synchronization flag (SYNC option) is set to Y.

system A system is a way to classify elements in CA SCM for Mainframe (defined to each environment where it will be used). A system typically represents the applications at a site. For example, you may have financial and manufacturing applications.

System Management Facilities (SMF) System Management Facilities (SMF) is IBM’s SMF.

System Management Facilities (SMF) interface The System Management Facilities (SMF) interface is an optional interface to IBM's System Management Facilities (SMF) that allows you to record historical information through SMF records. In CA SCM for Mainframe, they are called Action Records or Security Records. This information is used to generate historical reports. The implementation of the SMF interface is optional at each site, and the recording of historical information is optional within each environment.

Glossary 159

System Management Facilities (SMF) records System Management Facilities (SMF) records are written out if SMF recording is in effect, to document various CA SCM for Mainframe processing. An Action Record is written out at the end of (any) action processing, while a Security Record is written out for each security violation (or each error returned from the security exit, 01).

Transfer Elements Actions The Transfer Elements Action transports elements from a source location to a target location. Each location can be a CA SCM for Mainframe location or an archive data set.

transmission method The transmission method is a part of package shipment destinations to identify the transmission utility to be used to ship packages to the destination.

transportable footprint A transportable footprint is a CA SCM for Mainframe footprint that can be imbedded in DOS/VSE- and VM/CMS-bound object modules using a z/OS compiler, a VSE compiler, or a VM compiler.

type A type is a category of source code that is used as part of the classification of a CA SCM for Mainframe element. For example, there are types for COBOL (COBOL code), COPYBOOK (copybooks), JCL (JCL streams), and so forth.

type processing sequence A type processing sequence is a relative sequence of processing for the element types defined to each system. By defining a processing sequence, for example, you can make sure that copybooks (type COPYBOOK) are updated before any COBOL programs (type COB) that may use the copybooks.

Unload Utility The Unload Utility unloads and validates the contents of the VSAM Master Control Files (base and delta files associated with the environments and systems specified on the job request). The file created by the Unload function contains a backup of all internal MCF definitions (system, subsystem, type, type sequence, data set, element master record) and base or delta data (element base, element delta, component base, component delta). Packages contained within a package data set can also be unloaded. The utility can be run for an entire environment or for selected systems within an environment. Unload may also be directed to back up an entire package data set or individual packages.

Update Elements Action The Update Elements Action adds a member to CA SCM for Mainframe when an element with the same name is located in the target entry stage.


User Exit Table The User Exit Table identifies exit programs to be called at each CA SCM for Mainframe exit point.

user ID The user ID is used in TSO for actions that run in foreground for the session. For those actions run in batch, the user ID is the job name or the ID specified through the USER= parameter on the job card, depending on how your CA SCM for Mainframe Defaults Table is set up.

user menu facility The user menu facility allows your CA SCM for Mainframe administrator to attach user-defined functions to the CA SCM for Mainframe TSO/ISPF front end.

User Security Table The User Security Table defines the systems and subsystems to which users have access, and for each system and subsystem, the type of processing (authorization level) allowed. Each environment has one User Security Table.

validate The validate function allows you to ensure the integrity of one or more existing CA SCM for Mainframe environments and systems, and their related elements and components. These are the same checks performed as part of Unload processing, allowing this function to operate in a stand-alone mode.

version The version is a two-digit identifier associated with an element. You cannot have two versions of an element in the same environment.

version control Version control is the maintenance, tracking, and auditing of modifications to an application over time, allowing prior development versions to be restored.

version number The version number identifies the version assigned to an element.

vv.ll

The vv.ll identifier refers to a particular version (vv) and level (ll) of element source.

Index 161

Index

A abend, U0001 • 64 ACM Query Facility (ACMQ) • 68, 87 ALLOCATE service • 53 Alternatives for implementation • 102 Analyzing inventory • 108 Approval systems

replacing or upgrading existing system • 116

AUTHLIB considerations • 47 Automated Configuration Management (ACM) •

114 Automated Configuration Manager (ACM)

baseline creation • 123

B background verification • 80, 84 Backup and recovery procedures • 115 Base libraries • 113 base library

allocating • 88 Baseline creation of Automated Configuration

Manager (ACM) • 123 BC1JJB01 member

editing variables • 39 running • 39

BC1JJB02 member editing variables • 40 running • 40

C C1DEFLTS, CA SCM for Mainframe Defaults

Table • 61, 87 CA Common Services

components • 30 system requirements • 30

CA License Maintenance Program (LMP) about • 30 execution keys • 32 key certificate • 31

CA SCM for Mainframe Defaults Table (C1DEFLTS) • 61, 87 going into production • 125 organizational implementation • 91

running concurrent releases • 57 sample application • 59 test library • 88 testing • 85

CAIRIM • 30 Change Control Identifiers (CCIDs)

allocating and identifying • 115 concurrent releases, running • 57 Configuration management • 123 Conventions

naming of base/delta libraries • 111 type naming • 110

D Data sets

estimating size • 113 Defining

allocation of a package data set • 117 environments • 104 JCL streams • 121 libraries using symbolics • 112 map • 104 master control files • 106 physical structure • 111 processors • 121 software life cycle • 103 subsystems • 110 systems • 110 types • 110

Definition verification • 111 delta libraries • 113

allocating • 66, 88 System Inventory Summary • 72

E Element Catalog

copying • 86 synchronizing with MCFs • 87

Elements • 113 Emergency or quick fix procedures • 105 Enabling

package processing • 116 security • 123

Environment checking implementation • 107


definition • 104

F file integrity • 64 foreground verification • 75, 77 Forward delta format • 113

G Global Resource Sharing • 54

I implementation

alternatives • 102 checklist • 69 creating the ACM baseline • 123 environment checklist • 107 for source management • 103 process • 123 sample processors • 122 team selection • 93 verifying • 71

installation considerations • 47 data set • 39 JCL • 37 parameters • 37 readme file • 39 steps (administrator) • 11 steps (systems programmer) • 10 tape contents • 37

Internal training • 125 Inventory • 124

analysis • 108 loading • 123

inventory structure • 70 ISP Command table considerations • 58 ISPF

ALLOCATE service • 53 defining CA SCM for Mainframe data sets to

• 50 Environment panel • 72 LIBDEF services • 51 TSO FREE service • 53

J JCL

for System Inventory Summary Report • 72 installation • 37 sample application • 61

JCL streams definition • 121

L library

allocating • 88 copying • 85 processor load • 66 test • 88

licensing • 30 Life cycle development by normal procedure •

105 LINKLIST considerations • 48 LPA considerations • 48 LRECL settings for base and delta libraries •

114

M macros

TYPE=END • 61 TYPE=MAIN • 62

Map • 104, 106 Master Control File (MCF)

synchronizing with Element Catalog • 87 Master control files definition • 106

N Naming Conventions

for base/delta libraries • 111 for output libraries • 119

naming conventions, exceptions • 60 NDVRC1 authorization • 33

O Online and batch processing • 109 Organizational change

planning • 91 Output libraries • 119

P Package data set

definition, allocation,and processing • 117 PACKAGE FILE, allocating • 65 packages

copying the package file • 86 Parallel development mapping • 106 Physical structure definition • 111 Procedures for backup and recovery • 115

Index 163

processor load library executables • 66

Processors • 121

R readme file • 39 Resource Initialization Manager (CAIRIM) • 30 return codes • 70 Reverse delta format • 113

S sample application

defining inventory structure • 70 installation steps • 59 JCL • 61 naming conventions • 60 overview • 59 qualifiers • 60

Security enabling • 123

Software life cycle definition • 103

Source management implementation • 103

Stages for CA SCM for Mainframe control • 103 Statement of Integrity • 135 storage requirements, LPA Load Module • 49 Symbolics

defining CA SCM for Mainframe libraries • 112

System Inventory Summary Report • 72 Systems

profile (CONRPTO7) • 111

T tape contents, installation • 37 Training, internally • 125 TSO

logon procedures • 54 TSO FREE service • 53

two-level index file integrity • 64 U0001 abend • 64

Type naming conventions • 110

TYPE=END macro • 61 TYPE=MAIN macro • 62

U U0001 abend • 64 Using sample processors for implementation •

122

V verification

ACMQ • 83 background • 80 foreground • 75, 77

Verifying definitions • 111 VSAM

cluster • 65, 68 structure • 65

CA Software Change Manager for Mainframe Implementation Guide · CA Software Change Manager for...

Documents

Transcript of CA Software Change Manager for Mainframe Implementation Guide · CA Software Change Manager for...