ca endevor change mangaer

Administrator Guide r7 SP3

CA Endevor Change Manager

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 orwithdrawal by CA at any time.

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

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

The right to print copies of the documentation and to make a copy of the related software is limited tothe period during which the applicable license for the Product remains in full force and effect. Shouldthe license terminate for any reason, it shall be the user's responsibility to certify in writing to CA thatall 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 EXTENTPERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION “AS IS” WITHOUTWARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIESOF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT. INNO EVENT WILL CA BE LIABLE TO THE END USER OR ANY THIRD PARTY FOR ANY LOSS ORDAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDINGWITHOUT LIMITATION, LOST PROFITS, BUSINESS INTERRUPTION, GOODWILL, OR LOSTDATA, 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 applicablelicense agreement.

The manufacturer of this Documentation is CA.

Provided with “Restricted Rights.” Use, duplication or disclosure by the United States Government issubject to the restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) andDFARS Section 252.227-7014(b)(3), as applicable, or their successors.

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

Copyright 2006 CA. All rights reserved.

Contents

Chapter 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11.1 The Defaults Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21.2 The Software Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-31.3 CA Endevor Logical Structure . . . . . . . . . . . . . . . . . . . . . . . . 1-6

1.3.1 Using the Inventory Structure . . . . . . . . . . . . . . . . . . . . . 1-71.3.2 Setting Up CA Endevor . . . . . . . . . . . . . . . . . . . . . . . . . 1-7

1.3.2.1 Step 1: Determine Life Cycle Stages . . . . . . . . . . . . . . . 1-81.3.2.2 Step 2: Decide Stages for CA Endevor Control . . . . . . . . . 1-81.3.2.3 Step 3: Define Environments . . . . . . . . . . . . . . . . . . . . 1-81.3.2.4 Step 4: Define Systems . . . . . . . . . . . . . . . . . . . . . . 1-101.3.2.5 Step 5: Define Subsystems . . . . . . . . . . . . . . . . . . . . 1-111.3.2.6 Step 6: Define Types . . . . . . . . . . . . . . . . . . . . . . . 1-12

1.3.3 Classifying Elements . . . . . . . . . . . . . . . . . . . . . . . . . . 1-131.4 CA Endevor Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-151.5 Working with Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18

1.5.1 CA Endevor Actions . . . . . . . . . . . . . . . . . . . . . . . . . . 1-181.5.2 Actions by Job Function . . . . . . . . . . . . . . . . . . . . . . . . 1-191.5.3 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-201.5.4 Source and Output Management . . . . . . . . . . . . . . . . . . . 1-201.5.5 Creating Executable Forms of Elements . . . . . . . . . . . . . . . 1-201.5.6 Audit Stamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-211.5.7 Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21

1.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-221.6.1 Two Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-221.6.2 CA Endevor and Data Set Security . . . . . . . . . . . . . . . . . 1-22

1.7 Other Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-231.8 Name Masking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24

Chapter 2. A Conceptual View of Endevor . . . . . . . . . . . . . . . . . . 2-12.1 Inventory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

2.1.1 Automated Inventory Manager . . . . . . . . . . . . . . . . . . . . . 2-22.1.1.1 Logical Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22.1.1.2 Physical Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42.1.1.3 Interfaces to AllFusion CA-Panvalet and AllFusion

CA-Librarian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-52.2 Change Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

2.2.1 Automated Change Control . . . . . . . . . . . . . . . . . . . . . . . 2-62.2.1.1 Identifying and Tracking Changes . . . . . . . . . . . . . . . . 2-6

Contents iii

2.2.1.2 CA Endevor Change Manager Interface for IBM's TivoliInformation Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7

2.2.1.3 Automating Processes . . . . . . . . . . . . . . . . . . . . . . . . 2-72.2.1.4 Establishing Source-to-Executable Synchronization . . . . . . 2-92.2.1.5 Audit Management . . . . . . . . . . . . . . . . . . . . . . . . 2-11

2.2.2 Endevor Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-112.2.3 Endevor's Software Control Language (SCL) . . . . . . . . . . . . 2-12

2.3 Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . 2-142.3.1 CA Endevor Change Manager Automated Configuration Option 2-14

2.3.1.1 Defining Software Configurations . . . . . . . . . . . . . . . 2-142.3.1.2 Using Software Configurations . . . . . . . . . . . . . . . . . 2-17

2.4 Component Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-192.5 Release Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20

2.5.1 Automated Release Management . . . . . . . . . . . . . . . . . . 2-202.5.1.1 Change Administration . . . . . . . . . . . . . . . . . . . . . . 2-202.5.1.2 How It Works . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-212.5.1.3 Managing Production Turnover . . . . . . . . . . . . . . . . . 2-222.5.1.4 Managing Software Releases . . . . . . . . . . . . . . . . . . . 2-222.5.1.5 Release to Release Comparison . . . . . . . . . . . . . . . . . 2-24

2.6 Supporting Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . 2-252.6.1 CA Endevor Change Manager Parallel Development Option . . 2-25

2.6.1.1 Managing Parallel Development Activities . . . . . . . . . . 2-252.6.1.2 Managing Vendor Updates . . . . . . . . . . . . . . . . . . . 2-262.6.1.3 Basic PDM Operation . . . . . . . . . . . . . . . . . . . . . . . 2-26

2.6.2 Software Security Management . . . . . . . . . . . . . . . . . . . . 2-272.6.2.1 Native Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-272.6.2.2 CA Endevor Change Manager Interface for External Security 2-28

2.6.3 Software Information Management . . . . . . . . . . . . . . . . . 2-282.6.3.1 Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-292.6.3.2 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29

2.6.4 Endevor Benefit Summary . . . . . . . . . . . . . . . . . . . . . . . 2-30

Chapter 3. Defining Inventory Structures . . . . . . . . . . . . . . . . . . . 3-13.1 Basic Panel Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

3.1.1 The Environment Options Menu . . . . . . . . . . . . . . . . . . . . 3-43.1.2 Request and Selection Panels . . . . . . . . . . . . . . . . . . . . . . 3-5

3.2 Displaying Site Information . . . . . . . . . . . . . . . . . . . . . . . . . 3-73.2.1 Site Information Panel . . . . . . . . . . . . . . . . . . . . . . . . . . 3-73.2.2 Site Information Panel Fields . . . . . . . . . . . . . . . . . . . . . . 3-8

3.2.2.1 Customer Name Field . . . . . . . . . . . . . . . . . . . . . . . . 3-83.2.2.2 Function Controls Fields . . . . . . . . . . . . . . . . . . . . . . 3-83.2.2.3 Options Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-123.2.2.4 Package Processing Fields . . . . . . . . . . . . . . . . . . . . 3-133.2.2.5 Control Data Set Names Fields . . . . . . . . . . . . . . . . . 3-143.2.2.6 Endevor Parmlib Information . . . . . . . . . . . . . . . . . . 3-153.2.2.7 CA-7 Data Set Name Fields . . . . . . . . . . . . . . . . . . . 3-15

3.3 Displaying Stage Information . . . . . . . . . . . . . . . . . . . . . . . 3-163.3.1 Stage Information Panel . . . . . . . . . . . . . . . . . . . . . . . . 3-163.3.2 Stage Information Panel Fields . . . . . . . . . . . . . . . . . . . . 3-16

3.4 Defining Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-183.4.1 System Request Panel . . . . . . . . . . . . . . . . . . . . . . . . . 3-18

iv Administrator Guide

3.4.2 Procedure: New System . . . . . . . . . . . . . . . . . . . . . . . . 3-183.4.3 System Definition Panel . . . . . . . . . . . . . . . . . . . . . . . . 3-193.4.4 Using the System Definition Panel . . . . . . . . . . . . . . . . . . 3-193.4.5 System Definition Panel Fields . . . . . . . . . . . . . . . . . . . . 3-20

3.4.5.1 Identification Fields . . . . . . . . . . . . . . . . . . . . . . . . 3-203.4.5.2 General Options Fields . . . . . . . . . . . . . . . . . . . . . . 3-213.4.5.3 Element Registration Options . . . . . . . . . . . . . . . . . . 3-213.4.5.4 Signin/Signout Options Fields . . . . . . . . . . . . . . . . . 3-233.4.5.5 Last System Backup Fields . . . . . . . . . . . . . . . . . . . . 3-243.4.5.6 Processor Translation Output Libraries Fields . . . . . . . . 3-24

3.5 Cloning System, Subsystem, and Type Definitions . . . . . . . . . . . 3-263.5.1 Procedure: Cloning a New System . . . . . . . . . . . . . . . . . . 3-263.5.2 System Definition Panel for Cloning . . . . . . . . . . . . . . . . . 3-273.5.3 System Definition Panel Fields . . . . . . . . . . . . . . . . . . . . 3-27

3.5.3.1 To Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-273.5.3.2 From Information . . . . . . . . . . . . . . . . . . . . . . . . . 3-283.5.3.3 General Options . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28

3.6 Defining Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-293.6.1 Subsystem Request Panel . . . . . . . . . . . . . . . . . . . . . . . 3-293.6.2 Procedure: Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . 3-293.6.3 Subsystem Definition Panel . . . . . . . . . . . . . . . . . . . . . . 3-303.6.4 Using the Subsystem Definition Panel . . . . . . . . . . . . . . . 3-303.6.5 Subsystem Definition Panel Fields . . . . . . . . . . . . . . . . . . 3-30

3.7 Defining Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-323.7.1 Type Request Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-323.7.2 Procedure: Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-333.7.3 Type Definition Panel . . . . . . . . . . . . . . . . . . . . . . . . . 3-343.7.4 Using the Type Definition Panel . . . . . . . . . . . . . . . . . . . 3-343.7.5 Type Definition Panel Fields . . . . . . . . . . . . . . . . . . . . . 3-35

3.7.5.1 Identification Fields . . . . . . . . . . . . . . . . . . . . . . . . 3-353.7.5.2 Element Options . . . . . . . . . . . . . . . . . . . . . . . . . . 3-363.7.5.3 Component List Options . . . . . . . . . . . . . . . . . . . . . 3-413.7.5.4 Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41

3.7.6 Type Naming Conventions . . . . . . . . . . . . . . . . . . . . . . 3-423.7.7 Suggested Naming Standards . . . . . . . . . . . . . . . . . . . . . 3-423.7.8 Element Storage Formats . . . . . . . . . . . . . . . . . . . . . . . 3-42

3.7.8.1 Reverse Delta Considerations . . . . . . . . . . . . . . . . . . 3-433.7.8.2 Forward Delta Considerations . . . . . . . . . . . . . . . . . . 3-443.7.8.3 Full-Image Delta Considerations . . . . . . . . . . . . . . . . 3-44

3.7.9 Using Symbolics to Define Base and Delta Libraries . . . . . . . 3-443.8 Defining the Type Processing Sequence . . . . . . . . . . . . . . . . . 3-46

3.8.1 Type Sequence Request Panel . . . . . . . . . . . . . . . . . . . . . 3-463.8.2 Procedure: Type Processing Sequence . . . . . . . . . . . . . . . . 3-463.8.3 Type Processing Sequence Panel Fields . . . . . . . . . . . . . . . 3-48

3.9 Updating Type Data Set Definitions . . . . . . . . . . . . . . . . . . . 3-503.9.1 Type Data Set Request Panel . . . . . . . . . . . . . . . . . . . . . 3-503.9.2 Procedure: Type Data Set Definitions . . . . . . . . . . . . . . . . 3-503.9.3 Type Data Set Panel . . . . . . . . . . . . . . . . . . . . . . . . . . 3-513.9.4 Type Data Set Panel Fields . . . . . . . . . . . . . . . . . . . . . . 3-51

3.10 Displaying Environment Information . . . . . . . . . . . . . . . . . . 3-53

Contents v

3.10.1 Environment Information Panel . . . . . . . . . . . . . . . . . . . 3-533.10.2 Environment Information Panel Fields . . . . . . . . . . . . . . . 3-53

Chapter 4. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14.1 Defining a Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

4.1.1 Establishing Routes in the Defaults Table . . . . . . . . . . . . . . 4-34.1.2 Mapping Inventory Classifications . . . . . . . . . . . . . . . . . . . 4-3

4.2 Design Strategies and Guidelines . . . . . . . . . . . . . . . . . . . . . . 4-54.2.1 Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-54.2.2 Stand-alone Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-54.2.3 Converging Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-64.2.4 Converging Systems within a Route . . . . . . . . . . . . . . . . . . 4-74.2.5 Implementation Checklist . . . . . . . . . . . . . . . . . . . . . . . . 4-8

Chapter 5. Element Registration . . . . . . . . . . . . . . . . . . . . . . . . 5-15.1 Controlling Duplicate Element Names at the System and Subsystem

Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25.2 Controlling Duplicate Element Names at the Processor Group Level . 5-5

Chapter 6. Optional Features . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16.1 Endevor Optional Feature Table ENCOPTBL . . . . . . . . . . . . . . . 6-26.2 The Features Discussed in This Chapter . . . . . . . . . . . . . . . . . . 6-36.3 The Features Not Discussed in this Chapter . . . . . . . . . . . . . . . . 6-56.4 The CCID Definition Data Set . . . . . . . . . . . . . . . . . . . . . . . . 6-7

6.4.1 Install the CCID Definition Data Set . . . . . . . . . . . . . . . . . . 6-76.4.2 Step 1: Allocate the Data Set . . . . . . . . . . . . . . . . . . . . . . 6-76.4.3 Step 2: Initialize the Data Set . . . . . . . . . . . . . . . . . . . . . . 6-86.4.4 Step 3: Add the Data Set Name to the Defaults Table . . . . . . . 6-8

6.5 The SMF Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-96.5.1 Set the SMF Parameters in the Defaults Table . . . . . . . . . . . . 6-96.5.2 TYPE=MAIN Parameters . . . . . . . . . . . . . . . . . . . . . . . . 6-96.5.3 TYPE=ENVRNMNT Parameters . . . . . . . . . . . . . . . . . . . 6-10

6.6 The Endevor AllFusion CA-Panvalet Interface . . . . . . . . . . . . . 6-116.6.1 Link-Edit the Access Module . . . . . . . . . . . . . . . . . . . . . 6-116.6.2 Step 1: Edit BC1JPAN . . . . . . . . . . . . . . . . . . . . . . . . . 6-126.6.3 Step 2: Run BC1JPAN . . . . . . . . . . . . . . . . . . . . . . . . . 6-126.6.4 Step 3: Set the AllFusion CA-Panvalet Parameters in the

Defaults Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-126.7 The ++CONTROL Password Interface . . . . . . . . . . . . . . . . . . 6-13

6.7.1 Install the ++CONTROL Password Interface . . . . . . . . . . . . 6-136.7.2 Step 1: Edit BC1JCNTL . . . . . . . . . . . . . . . . . . . . . . . . . 6-136.7.3 Step 2: Run BC1JCNTL . . . . . . . . . . . . . . . . . . . . . . . . . 6-15

6.8 The Endevor AllFusion CA-Librarian Interface . . . . . . . . . . . . . 6-166.8.1 External and Internal Libraries . . . . . . . . . . . . . . . . . . . . 6-166.8.2 Set the AllFusion CA-Librarian Parameters in the Defaults Table 6-166.8.3 Should You Customize for AllFusion CA-Librarian? . . . . . . . 6-176.8.4 Considerations When Customizing . . . . . . . . . . . . . . . . . 6-176.8.5 Customize Your Site for the AllFusion CA-Librarian . . . . . . . 6-186.8.6 Step 1: Define Sequence Number Columns . . . . . . . . . . . . . 6-186.8.7 Edit the BC1JLIBR JCL . . . . . . . . . . . . . . . . . . . . . . . . . 6-196.8.8 Step 2: Define Endevor Types . . . . . . . . . . . . . . . . . . . . 6-20

vi Administrator Guide

6.8.9 Points to Remember . . . . . . . . . . . . . . . . . . . . . . . . . . 6-216.9 Alternate ID Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22

6.9.1 Implement Alternate ID Support . . . . . . . . . . . . . . . . . . . 6-226.9.2 Step 1: Set the Alternate ID Parameters in the Defaults Table . 6-226.9.3 Step 2: Build a Security Profile for Endevor Libraries . . . . . . 6-23

6.10 Site-Defined Symbolics . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-246.10.1 Defining Site Symbolics . . . . . . . . . . . . . . . . . . . . . . . . 6-246.10.2 Updating C1DEFLTS . . . . . . . . . . . . . . . . . . . . . . . . . 6-25

6.11 Parmlib Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-266.12 Type Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27

6.12.1 Implementing Global Type Sequencing . . . . . . . . . . . . . . 6-276.12.2 Defining the Type Sequence Member in the C1DEFLTS . . . . 6-27

Chapter 7. Site Symbolics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17.1 Site-Defined Symbolics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27.2 Site Symbolics Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3

7.2.1 Defining Site Symbolics . . . . . . . . . . . . . . . . . . . . . . . . . 7-37.2.2 Updating C1DEFLTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4

Chapter 8. Using CCIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-18.1 What CCIDs and/or Comments Indicate . . . . . . . . . . . . . . . . . 8-28.2 Requiring CCIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3

8.2.1 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-38.2.2 Action Prompt Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4

8.3 When Endevor Updates CCID Fields . . . . . . . . . . . . . . . . . . . . 8-58.3.1 Add Action CCID Updates . . . . . . . . . . . . . . . . . . . . . . . 8-5

8.3.1.1 Specifying an Add Action for a New Element . . . . . . . . . 8-68.3.1.2 Specifying an Add Action for an Existing Element . . . . . . 8-6

8.3.2 Update Action CCID Updates . . . . . . . . . . . . . . . . . . . . . 8-68.3.3 Retrieve Action CCID Updates . . . . . . . . . . . . . . . . . . . . . 8-78.3.4 Generate Action CCID Updates . . . . . . . . . . . . . . . . . . . . 8-7

8.3.4.1 Specifying a Generate Action without Copyback . . . . . . . 8-78.3.4.2 Specifying a Generate Action with Copyback . . . . . . . . . 8-7

8.3.5 Move Action CCID Updates . . . . . . . . . . . . . . . . . . . . . . 8-88.3.5.1 Specifying a Move Action without History . . . . . . . . . . . 8-88.3.5.2 Specifying a Move Action with History . . . . . . . . . . . . . 8-8

8.3.6 Transfer Action CCID Updates . . . . . . . . . . . . . . . . . . . . . 8-88.3.6.1 Specifying a Transfer Action without History . . . . . . . . . 8-88.3.6.2 Specifying a Transfer Action with History . . . . . . . . . . . 8-9

8.3.7 Delete Action CCID Updates . . . . . . . . . . . . . . . . . . . . . . 8-98.3.8 Restore Action CCID Updates . . . . . . . . . . . . . . . . . . . . 8-108.3.9 Summary CCID Impact Chart . . . . . . . . . . . . . . . . . . . . 8-10

8.4 Predefining CCIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-128.4.1 CCID Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-128.4.2 Endevor CCID Definition Data Set . . . . . . . . . . . . . . . . . . 8-13

8.4.2.1 Creating a CCID Definition Data Set . . . . . . . . . . . . . . 8-138.4.2.2 The Purpose of a Sequential Data Set . . . . . . . . . . . . . 8-148.4.2.3 Editing the File Using the ISPF Text Editor . . . . . . . . . . 8-14

8.4.3 Using the CCID Definition Data Set . . . . . . . . . . . . . . . . . 8-14

Contents vii

Chapter 9. SMF Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19.1 Record Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2

9.1.1 SMF Security Records . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29.1.2 SMF Action Records . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3

9.2 DSECT Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-59.2.1 $SMFHDDS DSECT: SMF Header Block . . . . . . . . . . . . . . . 9-59.2.2 $SMFREC1 DSECT: Security Record Data Block . . . . . . . . . . 9-79.2.3 $SMFREC2 DSECT: Action Record Data Block . . . . . . . . . . 9-119.2.4 $SMFBKDS DSECT: Action-Specific Blocks . . . . . . . . . . . . . 9-13

9.2.4.1 Environment Action-Block Detail Field Descriptions(SM2ENVDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17

9.2.4.2 Last Change Action-Block Detail Field Descriptions(SM2LCGDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19

9.2.4.3 Processor Information Action-Block Detail Field Descriptions(SM2LPRDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19

9.2.4.4 Request Parameter Info Action-Block Detail FieldDescriptions (SM2REQDS) . . . . . . . . . . . . . . . . . . . . . . . . 9-20

Chapter 10. Global Type Sequencing . . . . . . . . . . . . . . . . . . . . 10-110.1 Allocate the Parmlib Data Set . . . . . . . . . . . . . . . . . . . . . . . 10-310.2 Create Your Site's Type Sequence Member . . . . . . . . . . . . . . . 10-4

10.2.1 Syntax Rules for Type Records . . . . . . . . . . . . . . . . . . . 10-510.2.2 Sample Type Sequence File . . . . . . . . . . . . . . . . . . . . . 10-610.2.3 Build Utility for the Type Sequence Member . . . . . . . . . . . 10-6

10.3 Define the Type Processing Member . . . . . . . . . . . . . . . . . . 10-8

Chapter 11. The User Options Menu Facility . . . . . . . . . . . . . . . 11-111.1 Menu Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-211.2 User Option Menu Panel Overview . . . . . . . . . . . . . . . . . . . 11-3

11.2.1 Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-311.2.2 Modifying the User Options Menu . . . . . . . . . . . . . . . . . 11-4

Chapter 12. The ISPF Dialog Options Configuration Table . . . . . . . 12-112.1 Configuring ISPF Dialog Options . . . . . . . . . . . . . . . . . . . . 12-2

12.1.1 What You Can Change . . . . . . . . . . . . . . . . . . . . . . . . 12-212.1.2 What You Cannot Change . . . . . . . . . . . . . . . . . . . . . . 12-2

12.2 The Default Configuration Table . . . . . . . . . . . . . . . . . . . . . 12-312.3 Dialog Options Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5

Chapter 13. The Defaults Table . . . . . . . . . . . . . . . . . . . . . . . . 13-113.1 About the Defaults Table . . . . . . . . . . . . . . . . . . . . . . . . . 13-213.2 The C1DEFLTS Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-313.3 Editing the Defaults Table . . . . . . . . . . . . . . . . . . . . . . . . . 13-413.4 Assembling the Defaults Table . . . . . . . . . . . . . . . . . . . . . . 13-513.5 The TYPE=MAIN Macro . . . . . . . . . . . . . . . . . . . . . . . . . . 13-713.6 The TYPE=ENVRNMNT Macro . . . . . . . . . . . . . . . . . . . . . 13-2013.7 The TYPE=END Macro . . . . . . . . . . . . . . . . . . . . . . . . . . 13-26

Chapter 14. The Alternate Defaults Table . . . . . . . . . . . . . . . . . 14-114.1 About ENUXSITE Program . . . . . . . . . . . . . . . . . . . . . . . . 14-214.2 Parameters Passed to the ENUXSITE Program . . . . . . . . . . . . 14-3

viii Administrator Guide

14.3 How to Use the ENUXSITE Program . . . . . . . . . . . . . . . . . . 14-414.4 How to Create an Alternate Defaults Table . . . . . . . . . . . . . . 14-514.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-6

Chapter 15. Performance and Tuning . . . . . . . . . . . . . . . . . . . . 15-115.1 Choosing Between Delta Formats . . . . . . . . . . . . . . . . . . . . 15-215.2 Setting the Element Delta Consolidation Level . . . . . . . . . . . . 15-415.3 Mapping Multiple Environments . . . . . . . . . . . . . . . . . . . . . 15-515.4 Selecting a Library Type for Base and Delta Members . . . . . . . . 15-6

15.4.1 Benefits and Drawbacks of Library Types . . . . . . . . . . . . . 15-615.4.2 Converting from One Library Type to Another . . . . . . . . . 15-8

15.5 Using CA-L-Serv for Endevor's VSAM File Processing . . . . . . . 15-915.5.1 Setting the RECBUFFSIZE Parameter . . . . . . . . . . . . . . . 15-915.5.2 Monitoring CA-L-Serv's Performance . . . . . . . . . . . . . . . 15-9

15.5.2.1 Evaluating Buffer Pool Usage . . . . . . . . . . . . . . . . . 15-1015.5.2.2 Displaying Information about the Communications Server 15-10

15.6 Using z/OS SYSPLEX VSAM Record Level Sharing (RLS) Supportfor MCFs and Package Data Set . . . . . . . . . . . . . . . . . . . . . . . . 15-11

15.7 Tuning Your Processors . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1315.8 Tuning Your System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-14

Appendix A. Converting Delta Formats . . . . . . . . . . . . . . . . . . . A-1A.1 Steps for Converting Forward to Reverse Delta . . . . . . . . . . . . A-2

A.1.1 Procedure Summary . . . . . . . . . . . . . . . . . . . . . . . . . . A-2A.1.2 Step 1: Analyzing Existing Types . . . . . . . . . . . . . . . . . . A-2A.1.3 Step 2: Resize and Allocate New Base Libraries . . . . . . . . . A-3A.1.4 Step 3: Resize the Delta Libraries . . . . . . . . . . . . . . . . . . A-3A.1.5 Step 4: Evaluate and Modify Processors . . . . . . . . . . . . . . A-3A.1.6 Step 5: Run a Full Unload of Each Environment . . . . . . . . . A-3A.1.7 Step 6: Adjust Type Definitions . . . . . . . . . . . . . . . . . . . A-4A.1.8 Step 7: Reload Inventory by System . . . . . . . . . . . . . . . . A-4A.1.9 Step 8: Validate the Results . . . . . . . . . . . . . . . . . . . . . . A-5

A.2 Additional Conversion Notes . . . . . . . . . . . . . . . . . . . . . . . A-6A.3 Procedure for Converting Forward/Reverse Delta to Full-Image

Delta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7

Appendix B. Catalog Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . B-1B.1 Building the Element Catalog . . . . . . . . . . . . . . . . . . . . . . . . B-2

B.1.1 Step 1: Converting Your Existing MCF VSAM Data Sets . . . . . B-2B.1.2 Step 2: Converting Your Existing Package VSAM Data Sets . . . B-2B.1.3 Step 3: Defining the MCF Catalog Data Set . . . . . . . . . . . . . B-3B.1.4 Step 4: Updating the C1DEFLTS Table . . . . . . . . . . . . . . . . B-3B.1.5 Step 5: Running the Catalog Build Utility . . . . . . . . . . . . . . B-3

B.2 CA Endevor Considerations . . . . . . . . . . . . . . . . . . . . . . . . . B-6B.3 Catalog Rename Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-7B.4 Catalog Synchronization Utility . . . . . . . . . . . . . . . . . . . . . . . B-9

B.4.1 Catalog Synchronization Utility JCL . . . . . . . . . . . . . . . . . . B-9B.4.2 Catalog Synchronization Utility Syntax . . . . . . . . . . . . . . . B-10B.4.3 Catalog Synchronization Utility Sample Report . . . . . . . . . . B-11

Contents ix

Appendix C. Interfacing CA Endevor with CA Common Services . . . C-1C.1 Formatting CA Endevor Messages . . . . . . . . . . . . . . . . . . . . . C-2C.2 How the Interface Works . . . . . . . . . . . . . . . . . . . . . . . . . . . C-3C.3 Calling the Interface From a User Exit . . . . . . . . . . . . . . . . . . . C-4C.4 Calling the Interface From a Processor . . . . . . . . . . . . . . . . . . . C-5

C.4.1 Sample CA Endevor Processor Fragment . . . . . . . . . . . . . . C-5C.4.2 REXX Procedure Sample . . . . . . . . . . . . . . . . . . . . . . . . C-6

C.5 Setting Up the IP Addresses of Event Consoles . . . . . . . . . . . . . C-7

Appendix D. Long Name and HFS File Support . . . . . . . . . . . . . D-1D.1 Long Name and HFS Support Overview . . . . . . . . . . . . . . . . D-2

D.1.1 HFS Path Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-2D.1.2 HFS Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-2D.1.3 Element Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-3D.1.4 Long Name Support and CA Endevor Interfaces . . . . . . . . . D-4

D.2 Long Name Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-6D.2.1 Adding and Retrieving Long Name Elements . . . . . . . . . . D-6D.2.2 Storing Long Name Elements . . . . . . . . . . . . . . . . . . . . D-7D.2.3 Displaying Element Information . . . . . . . . . . . . . . . . . . . D-7

D.3 HFS Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . D-8D.3.1 HFS Directories and CA Endevor Libraries . . . . . . . . . . . . D-8D.3.2 Using Site Symbolics for Type Definitions . . . . . . . . . . . . . D-9D.3.3 HFS Directories and CA Endevor Actions . . . . . . . . . . . . . D-10D.3.4 HFS Files and CA Endevor Actions . . . . . . . . . . . . . . . . . D-10

D.4 HFS RECFM Field in Type Definition Panel . . . . . . . . . . . . . . D-11

Appendix E. Working with Binary Files . . . . . . . . . . . . . . . . . . . E-1

Appendix F. Email Notification . . . . . . . . . . . . . . . . . . . . . . . . . F-1F.1 Email Notification Components . . . . . . . . . . . . . . . . . . . . . . . F-2F.2 $ESMTP Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F-3F.3 Sample ESMTPTBL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F-5F.4 BC1JSMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F-6

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X-1

x Administrator Guide

Chapter 1. Overview

CA Endevor Change Manager (CA Endevor) is an integrated set ofmanagement tools that is used to automate, control, and monitor yourapplications' development process. Using CA Endevor, you can do thefollowing:

■ Automatically compare and track your changes against production,creating an online change history. This speeds up the debugging processand enables you to always know what was changed, by whom, and why.

■ Prevent conflicting changes to the same system component.

■ Browse and manipulate all components relating to an application from asingle screen, saving you time and ensuring that changes are complete.

■ Create executables automatically.

■ Ensure that the source, executable, and any other form (for example,listings) of an element correspond.

■ Apply the same procedures (including automating compiles, analyzingimpacts, and standards checking functions) to any component type,dramatically simplifying the standardization process.

■ Put change packages and approvals online, eliminating change-relatedpaperwork.

■ View or retrieve prior levels of any element.

■ Report on element definition, content, and change history.

■ Enforce change control procedures.

CA Endevor is implemented and run under z/OS, within the TSO ISPFenvironment, and in batch.

This manual explains the administrative aspects of CA Endevor. This rest ofthis chapter introduces basic CA Endevor concepts.

Chapter 1. Overview 1-1

1.1 The Defaults Table

1.1 The Defaults Table

The CA Endevor Defaults Table contains your global system information, suchas CA Endevor options installed at your site, CA Endevor control data setnames, and settings available for CA Endevor features. Although all of theseparameters are set at system installation, you may need to change the DefaultsTable if your site purchases a new CA Endevor product, your library nameschange, or you want to tailor the information entered by the system installer.The table comprises a set of "C1DEFLTS" macros which, when assembled andlink-edited, are known collectively as the Defaults Table.

The Defaults Table should reside in an authorized data set.

For a sample of the C1DEFLTS table and a detailed description of theparameters available within the table, see the chapter "The Defaults Table."

1-2 Administrator Guide

1.2 The Software Life Cycle


CA Endevor allows you to automate and control the movement of softwarethrough your software life cycle.

Software life cycles are site-specific. A representative life cycle might consistof five stages:

■ DEV — Programs are developed.

■ TEST — Programs are unit tested.

■ QA — Applications are system tested.

■ EMER — Fixes are applied to production code.

■ PROD — Production applications reside.

Note: This example illustrates one life cycle. CA Endevor can beimplemented to adapt to any software life cycle requirements.

Basic Operations: Normal change procedures include the following:

■ Retrieving elements from production to a development library.

■ Making changes to elements.

■ Adding/updating elements into the test stage.

■ Moving elements to QA.

■ Moving elements to production.



The following diagram shows normal change procedures in a software lifecycle:

Emergency change procedures include the following:

■ Retrieving elements from production.

■ Making changes to elements.

■ Adding/updating elements into the emergency stage.

■ Moving elements to production.



The following diagram illustrates emergency change procedures in a softwarelife cycle:


1.3 CA Endevor Logical Structure


CA Endevor helps to manage the software life cycle by providing a consistentand flexible logical structure for classifying software inventory. There are sixcomponents to this inventory structure: environments, stages, systems,subsystems, types, and elements. Environments, stages, systems, subsystems,and types are set up by the CA Endevor administrator. Users act on elements.These terms are defined next:

Term Description

Environment Functional areas within an organization. For example, theremight be separate development and production environments.There is no limit to the number of environments that may bedefined.

Stage The stages in the software life cycle. (For an example, see 1.2,“The Software Life Cycle” on page 1-3.) Each environmentalways has one or two stages. Each stage is assigned a uniquename and ID, representing their place life cycle. For example,TEST and an ID of 1, or QA and an ID of 2. Stages arereferred to in this manual as Stage 1 (the first stage in anenvironment) and Stage 2 (the second stage in anenvironment). Stages can be linked together to establishunique promotion routes for program inventory within andbetween environments. These routes make up the map for asite.

System The applications at a site. For example, there might befinancial and manufacturing applications. A system must bedefined to each environment in which it is used.

Subsystem A specific application within a system. For example, theremight be purchase order and accounts payable applicationswithin the financial system. Keep in mind that:

■ There must be at least one subsystem per system. Asubsystem must be defined to each system in which it isused. For example, to create subsystem PO within systemFinance in the environments TEST, QA, and PROD, youmust define subsystem PO in each environment.

■ A subsystem can have the same name as the system towhich you define it.



Term Description

Type Categories of source code. For example, you might create thefollowing types:

■ COBOL - for COBOL code■ COPYBOOK - for copybooks■ JCL - for JCL streams

You must define a type to each stage in which you want touse it.

Element Partitioned data set (PDS) members, AllFusionCA-Panvalet, AllFusionCA-Librarian, or sequential datasets that have been placed under control of CA Endevor. Bydefault, the element name is the member name. Each elementis classified by system, subsystem, and type. Its environmentand stage determine its location in the software life cycle.

1.3.1 Using the Inventory StructureThe CA Endevor inventory structure allows you to do the following:

■ Work with program modules without having to know where they arephysically located, or how they are compiled.

■ List all the program components that make up an application, regardless oftype.

■ Determine the location(s) of an element simply by entering the elementname on a display screen.

■ Act on a cross section of your program inventory. For example, CAEndevor allows you to list all COBOL code in your shop, or promote anentire new release of the payroll application with a single command.

1.3.2 Setting Up CA EndevorThe CA Endevor administrator builds an inventory structure based on thestages in your site's software life cycle. There are six steps in setting up aninventory structure:

1. Determine the stages in the software life cycle.

2. Decide which stages should be put under the control of CA Endevor.

3. Define two-stage environments based on the decisions in Steps 1 and 2,and link these environments and stages together to form a map.

4. Define applications (systems) for each stage.

5. Define specific applications (subsystems) within each system.

6. Define the types of code present at each system stage and the processingrequired for each.



1.3.2.1 Step 1: Determine Life Cycle Stages

Software life cycles are site-specific. For this example, consider a five-stage lifecycle:

DEV UNITTEST QA EMER PROD

1.3.2.2 Step 2: Decide Stages for CA Endevor Control

You can decide to put some or all of the stages in your life cycle under controlof CA Endevor. In this example, assume the last four stages of the life cycleare under the control of CA Endevor:

UNITTEST QA EMER PROD

This means that program development takes place outside of CA Endevor.

While this is a fairly typical life cycle, keep in mind that CA Endevor can beadapted to any life cycle.

1.3.2.3 Step 3: Define Environments

Environment is the CA Endevor term for functional areas in your organization.In this example, assume that the UNITTEST and QA stages in the life cycle arepart of the development function, and that production applications and theirmaintenance are part of a function called production. The administratordefines environment TEST to include Stages UNITTEST and QA, and a secondenvironment called PROD, that includes Stages EMER and PROD.Development activities take place in a development library, outside of CAEndevor. This is illustrated by the following diagram:



The Environment Map — The CA Endevor administrator might decide toestablish the following route for inventory at this site that promotes inventoryfrom Stage UNITTEST to Stage QA to Stage PROD:

Emergency fixes would be moved from stage EMER to stage PROD.



1.3.2.4 Step 4: Define Systems

You must define a system to each environment in which you plan to use it.There are two systems in this example: FINANCE and MFG (manufacturing).This is illustrated by the following diagram:



1.3.2.5 Step 5: Define Subsystems

You must define at least one subsystem for each system. In this example,system FINANCE has two subsystems: PO and AP. System MFG has onesubsystem, MFG. This is illustrated by the following diagram:



1.3.2.6 Step 6: Define Types

You must define types to each system/stage combination in which you plan touse them. All subsystems defined to a system can use the types defined tothat system. You must define types at each stage in an environment. In thisexample, system FINANCE has available the types, COBOL (COBOL code),JCL (JCL streams), and COPYBOOK (copybooks). System MFG has availablethe types, ASSEM (Assembler code), JCL, and MACRO (Macros). This isillustrated by the following diagram:



1.3.3 Classifying ElementsCA Endevor classifies elements according to the inventory structure you setup. Each element is described uniquely in terms of its:

■ Location in the software life cycle. This is determined by the environmentand stage where it resides.

■ Inventory classification. This is determined by the system, subsystem, andtype with which it is associated.

This is illustrated by the following diagram:



For example, in this diagram, elements are classified as follows:

Querying the CA Endevor Structure: The CA Endevor classification schemeallows users to produce lists of elements by environment, stage, system,subsystem, type, or any combination of these categories. For example, usingthe preceding example, you could query the system for the following lists:

This module Is located in Is classified as

PROG01 Environment TESTStage UNITTEST Type COBOL

Subsystem POSystem FINANCE

JCL22Q Environment TESTStage QA

Type JCLSubsystem MFGSystem MFG

COPY33 Environment TESTStage QA

Type COPYBOOKSubsystem APSystem FINANCE

This query Produces

Show me all the JCL in the shop JCL56JCL008JCL22Q

Show me all the software currently in QA PROGXJCL008COPY33PGM00JCL22QMAC02

Show me all the manufacturing software currently beingunit tested

PGMA1PGMA2MAC02


1.4 CA Endevor Libraries


To implement an inventory structure, certain libraries must first be definedand allocated. The following table describes these libraries briefly:

Library Description

Master Control Filelibraries

There is one Master Control File (MCF) for every stage. A Master ControlFile stores system, subsystem, and type definitions, the names of the elementscurrently in that stage, and other information.

Master Control File libraries are defined in the Defaults Table.

Element Catalog The element catalog is a VSAM KSDS file, similar to the master control file(s)and the package control file. The element catalog enables the support forlong or mixed-case element names.

When an element with a long or mixed-case name is added to CA Endevor,the original name is maintained in the element catalog, and an CAEndevor-generated short name (eight characters) is stored in the associatedmaster control file entry. An additional VSAM KSDS file, known as thecatalog Cross Reference file, is also maintained, so that actual element namescan be retrieved using the short element name that is stored in the MCF.

The element catalog contains one element catalog record for eachelement-type occurrence and each element catalog record contains a datasegment for each location (MCF) where an element resides.

There are limitations associated with the element catalog:

■ A given MCF can be associated with only one catalog■ One catalog can be associated with many MCFs■ One catalog can be associated with many C1DEFLTS tables

The key of the element catalog file is 255 characters long. It consists of thefollowing:

1. The first 240 characters of the element name. The remaining 15characters of the element name are actually stored in the base portion ofthe record.

2. The element type name

The information supplied to CA Endevor determines whether the elementcatalog or the MCF file is used during element searches. For example:

■ If the system and subsystem names are provided, but not the elementname — the MCF is searched.

■ If an element name is specified — the element catalog is searched;regardless of the system and subsystem specifications.)

Package data set There is one package data set per site. CA Endevor stores all packages builtat the site, and related information, in this data set.

You define the package data set for your site in the Defaults Table.



Library Description

Base and deltalibraries

CA Endevor uses base and delta libraries to store source code. Base librariesstore source when it is first added to CA Endevor. Delta libraries storechanges made to the source. Generally, there is one set of base and deltalibraries associated with each type definition.

Base and delta libraries are defined during implementation on the typedefinition panel.

ACM Root and XREFLibraries

CA Endevor uses these libraries to store the name of each element and itsrelated components. This data set is required if your site uses the ACMQuery Facility. For more information, see the Automated Configuration OptionGuide.

The ACM library for your site is defined in the C1DEFLTS table.

Output libraries �1� CA Endevor uses output libraries to store executable forms of programsproduced by processors. Allocate these libraries by stage.

You allocate output libraries during CA Endevor implementation.

Source outputlibraries

CA Endevor uses source output libraries to store copybooks, assemblermacros, or JCL procedures that are copied elsewhere and therefore have to beavailable in full source form.

Note: Source output libraries are type-specific. You can define a sourceoutput library for each type in a stage, or share one library across types.Generally, source output libraries are not needed if you store elements inreverse delta format.

You define the source output libraries on the type definition panel.

Processor load andlisting libraries �1�

CA Endevor uses processor load libraries to store the executable form of CAEndevor processors. Allocate one processor load library for both stages ofyour production environment; point to these libraries from all other stages.

Processor listing libraries are optional. CA Endevor uses them to storelistings when processors are compiled.

CA Endevor listinglibraries �1�

Used to store compiler listings produced by the CONLIST utility. A singlelibrary can be shared across systems.

Listing libraries are optional if you do not use CONLIST in your processors.You allocate listing libraries during CA Endevor implementation.

Include libraries CA Endevor uses include libraries to store the full form of AllFusionCA-Panvalet (++INCLUDE) and AllFusion CA-Librarian (-IN) includestatements.

You allocate include libraries on the type definition panel.

Processor outputlibraries �1�

These are libraries that you refer to in processors, to which processors writetheir output. Processor output libraries can be source libraries, executablelibraries, or listing libraries.

Note: �1� — Processors only



The following table summarizes where each of these libraries should beallocated in a sample software life cycle:

Library Name C1DEFLTS DEVTEST

DEV QA PRODEMERG

PRODPROD

Master control files x

Element Catalog x

ACM Root library x

ACM XREF library x

Package data set x

Base and delta libraries, bytype

x x x x

Output libraries, by type x x x x

Source output libraries, bytype

x x x x

Processor load libraries x

Processor output libraries(source, executable, list)

x x x x

Include libraries, by type x x x x


1.5 Working with Elements


This section describes how to work with elements in CA Endevor.

1.5.1 CA Endevor ActionsYou manipulate CA Endevor inventory by executing ENDEVOR commandscalled actions. Some actions are available in both foreground and in batch,while others are available only in batch. Batch actions are also available whenyou build packages. For more information, see the following guides:

■ The User Guide explains how to execute actions in foreground and submitbatch action requests.

■ The SCL Reference Guide contains the syntax for CA Endevor's SoftwareControl Language (SCL). SCL allows you to code CA Endevor batchaction requests.

The following table summarizes CA Endevor actions and their availability:

Action Available inForeground

Availablein Batch

Function

Add x x Puts a member under CAEndevor control from anexternal data set.

Archive x Writes the current version ofan element to a sequentialdata set.

Copy x Copies an element from anarchive data set to a data setexternal to CA Endevor.

Delete x x Erases base and delta formsof an element and removesrelated information from aMaster Control File.

Display x Displays information aboutan element.

Generate x x Creates an executable formof an element.

List x Creates a list of elementsthat meet specific selectioncriteria. One effective use ofthis function is to performimpact analysis.



Action Available inForeground

Availablein Batch

Function

Move x x Moves elements betweenstages, within or acrossenvironments.

Print x x Prints element or memberinformation.

Restore x Restores elements to CAEndevor from an archivedata set.

Retrieve x x Copies elements from CAEndevor to an external dataset.

Signin x x Removes the user signoutassociated with an element.

Transfer x Moves elements betweenlocations that are not on thesame map route.

Update x x Updates an element from anexternal data set.

1.5.2 Actions by Job FunctionA typical site might include the following job functions:

■ Development

■ QA/Test

■ Turnover

■ Audit

■ Management

■ CA Endevor administration

The following table summarizes for each job function the actions that someonemight perform:

Action Dev QA/Test Turnover Audit Mgmnt Admin

Add/Update x x x

Archive x

Copy x

Delete x x



Action Dev QA/Test Turnover Audit Mgmnt Admin

Display x x x x x x

Generate x

List x x

Move x x x x

Print x x x x x x

Restore x

Retrieve x x x

Signin x x x

Transfer x x

1.5.3 ReportingCA Endevor provides a full set of standard reports. For more information, seethe Reports Guide.

1.5.4 Source and Output ManagementAs it executes each action request, CA Endevor categorizes the processing assource management or output management.

■ Source management deals with that aspect of processing that maintains theelement source and MCF definitions; that is, updates to the MasterControl File and to the base and delta libraries.

■ Output management relates to any processing that creates or maintainsdata sets related to the element being processed. These data sets includethe source output libraries, processor listing and load libraries (applicablefor element type PROCESS only), user-defined libraries, and INCLUDElibraries.

Note: Output management is only available if you have the CA Endevorprocessor component.

1.5.5 Creating Executable Forms of ElementsCA Endevor uses OS JCL streams called processors to create executable formsof source code, including source modules, object modules, load modules, andlistings.



There are three kinds of processors:

■ Generate processors execute automatically when an element is added orupdated in the entry stage, or generated in either stage. Optionally,generate processors execute when an element is restored or transferred toCA Endevor from an archive data set.

Typically, the generate processor creates an executable form of the element,together with any associated outputs (such as listings).

■ Move processors move elements from one stage in the life cycle to another.Move processors generally copy all the output previously created for theelement, or recreate those outputs in the target stage.

■ Delete processors execute automatically when an element is deleted,transferred, moved, or archived. (You can bypass this automatic delete fortransfer, move and archive requests.) Generally, the delete processordeletes any output that was created by the corresponding generateprocessor.

Processors are combined into processor groups. A processor group consists ofone generate, one move, and one delete processor, as well as the symbolicoverrides for the processors' JCL. For more information, see the ExtendedProcessors Guide.

1.5.6 Audit StampsCA Endevor can place an encrypted audit stamp, called a footprint, in theoutput source, object, or load modules that are created by processors. Thefootprint provides an integrity check between the source form of an elementand its executable form.

1.5.7 PackagesCA Endevor packages allow you to formalize your use of actions by:

■ Creating sets of actions that can be tracked, maintained, and reused as aunit.

■ Establishing approval procedures for packages.

■ Centralizing package location, facilitating their reuse across environments.

■ Shipping packages to remote locations.

For more information, see the Packages Guide.


1.6 Security

1.6 Security

This section describes the security features provided by CA Endevor.

1.6.1 Two OptionsCA Endevor provides two functional security options:

■ A native security facility

■ The CA Endevor External Security Interface (CA Endevor ESI)

A native security facility comes with CA Endevor. It enables you to secure CAEndevor functions (access and actions) by using security tables. For moreinformation, see the Security Guide.

The External Security Interface is an optional feature that enables you to secureCA Endevor functions (access and actions) through the z/OS Security AccessFacility (SAF) and in conjunction with the installation security package on yoursystem. It does this by allowing you to define the rules for function security inyour installation security package (RACF, eTrust CA-ACF2 Security,eTrust CA-Top Secret Security) rather than in the native tables suppliedwith CA Endevor. For more information on enabling and using CA EndevorESI, see the Security Guide.

1.6.2 CA Endevor and Data Set SecurityCA Endevor does not provide data set security. Data set security is performedby an installation security package, such as:

■ RACF

■ eTrust CA-ACF2 Security

■ eTrust CA-Top Secret Security

CA recommends that you implement data set security to prevent unauthorizedaccess to the data sets controlled by CA Endevor. For information on how toaccomplish this using your installation security package, see the Security Guide.


1.7 Other Capabilities

1.7 Other Capabilities

In conjunction with other CA products, CA Endevor can provide:

■ Configuration management, using the CA Endevor AutomatedConfiguration Manager (ACM). For more information, see the AutomatedConfiguration Option Guide.

■ Parallel development controls using the CA Endevor Parallel DevelopmentManager (PDM). For more information, see the Parallel Development OptionGuide.

■ Automated coordination of all DB2 processes, using the CA Endevor forDB2 Application Manager.

■ Footprint synchronization at remote sites.

■ Interfaces to:

– IBM Tivoli Information Management System

– Advantage CA-RoscoeInteractive Environment

– AllFusion CA-Panvalet and AllFusion CA-Librarian

– Unicenter CA-7

– Unicenter CA-Netman


1.8 Name Masking

1.8 Name Masking

A name mask allows you to specify all names, or all names beginning with aparticular string, to be considered when performing an action.

Name masks are valid on:

■ Element names

■ System, subsystem, and type names within FROM clauses

■ Report syntax

■ ISPF panels

■ API requests

■ Package IDs

Name masks are not valid on:

■ Environment names

■ Element names in the following situations:

– When entering a LEVel in a statement

– When using the MEMber clause with a particular action

– When building a package

Usage: There are three ways to mask names: by using the wildcard character(*), by using the placeholder character (%), and by using both together.

The wildcard (*) can be used in one of the following two ways to specifyexternal file names:

■ When coded as the only character of a search string, CA Endevor returnsall members of the search field. For example, if you coded the statementADD ELEMENT *, all elements would be added.

■ When coded as the last character of a search string, CA Endevor returns allmembers of the search field beginning with the characters in the searchstring preceding the wildcard. For example:

– The statement ADD ELEMENT UPD* would add all elementsbeginning with "UPD", such as UPDATED or UPDATE.

– PKG* would return all package IDs beginning with PKG.

Note: You cannot use more than one wildcard in a string. The statementADD ELEMENT U*PD* would result in an error.


1.8 Name Masking

The placeholder (%), which represents any one character in a string can also beused in one of the following two ways:

■ When coded as the last character in a string, CA Endevor returns allmembers of the search field, beginning with the characters in the searchstring preceding the placeholder, but which have no more characters thanwere coded in the search string.

– If you coded the statement ADD ELEMENT UPD%, only thoseelements with four-character-long names beginning with "UPD" (UPD1or UPDA, for example) would be added.

– PKG% returns PKGS, PKGB, PKGC, and so on.

■ It is also possible to use the placeholder multiple times in a single searchstring. The statement ADD ELEMENT U%PD% would return all elementswith five-character-long names that have U as the first character, and PDthird and fourth.

The wildcard and the placeholder can be used together, provided that thewildcard appears only at the end of the search string and is used only once.For example:

■ The statement ADD ELEMENT U%D*, which uses both the wildcard andthe placeholder, would add elements with names of any length that haveU as the first character, any one character as the second character, and Das the third character.

■ P%G* returns PKGABCD, POGS, PIGGY, PPG1234NDVR, and so on.


Chapter 2. A Conceptual View of Endevor

Endevor provides automated facilities for performing all software managementtasks from inventory management and change control to configuration andrelease management. These facilities are further enhanced throughcomprehensive change administration, parallel development management,software security and software information management facilities. As afully-integrated, single-vendor solution, Endevor dramatically improves theoperation and administration of IBM mainframe installations by providing thefollowing:

■ A comprehensive inventory of all programs and software assets that residein partitioned data sets (PDSs), library management systems, HFSdirectories, and executable libraries

■ An absolute history of all changes that have occurred to the source

■ Control of the processes and procedures that translate source intoexecutableforms

■ An inviolate and auditable link between the source code and its relatedexecutable forms

■ Protection and control of inventory items through extended security

■ Automated cross-referencing of software component relationships forpurposes of historical analysis, change impact analysis, recreation of priorversions, and release management

■ Control and automation of the movement and distribution of softwarerelease packages from stage to stage, site to site, and across networks

Endevor accommodates the diversity of both small-scale and large-scale ISoperations. And Endevor works in conjunction with existing procedures,structures and standards, rather than imposing new ones.

Chapter 2. A Conceptual View of Endevor 2-1

2.1 Inventory Management


In most organizations, the application inventory is large, complex, and alwayschanging. Today's applications have graduated beyond standard source toinclude a wide variety of components—most outstripping traditional80-character storage limitations. In addition to the changing complexion of theinventory's physical structure, there is a growing proliferation of physicallibraries and functional environments (Test, QA, Production, and so on).Programmers and IS support personnel typically require intimate knowledgeof those library structures as they relate logically to business units within anorganization. This logical view, divorced from the physical storage structure, isrequired both to ensure that logically related inventory elements are beingmanipulated consistently and correctly, and to provide a common userinterface regardless of physical structures. An effective inventory managementstructure also forms the foundation for change control, configurationmanagement, and release management activities.

2.1.1 Automated Inventory ManagerTraditional software classification systems (PDSs, library management systems,and so forth) provide limited inventory classification capabilities and highlyrestrictive methods for storing and recreating prior versions of softwaremodules. When using these traditional systems, IS departments resort tocomplex naming conventions and physical separate libraries to obtain asemblance of organization. This indirect naming and storage technique is botherror-prone and inflexible. Consequently, as programmers move from projectteam to project team, they are forced to learn and relearn the peculiarities ofmanipulating the software inventory as applied by each project team. Clearly,a common technique is required for classifying software throughout the ISorganization, one that provides both consistency and flexibility.

2.1.1.1 Logical Structure

Endevor employs advanced classification techniques that form the necessaryfoundation for categorizing, viewing, and manipulating the applicationsoftware inventory in a consistent manner. An inventory item (element) isidentified to Endevor's Inventory manager by a fully-qualified name consistingof its environment, stage (location), system, subsystem, type, and elementname.

Environment, Stage-As an application is modified and its elements are movedthroughout the software development life cycle, those elements may reside indifferent functional locations (Test, QA, Production, Backup, and so on) atdifferent times. Within Endevor's inventory classification scheme, the locationof an element is part of the identification of that element.



System-Systems represent the logical grouping of inventory elements as theyapply to major applications, departments, or work areas within anorganization. Typically, a system is the "organizational owner" of a portion ofthe inventory. For example, the systems in an organization might includeFinance, Personnel, and Manufacturing.

Subsystem-Subsystems are logical sub-classifications within systems. Forexample, the Finance system might be divided into logical subsystems such asGeneral Ledger, Accounts Receivable, Accounts Payable, Common Routines,and Reports.

Type-Within the application inventory, types represent the form of theelement, indicating how the element is created (the source language used) andhow it is manipulated. For example, the Finance system might have severaltypes of elements, including COBOL programs, Assembler programs, Cprograms, PL/I programs, copy members, Assembler macros, screendefinitions, and linkage editor statements.

Element Name-The element name is the existing name of the element becauseit is already established. This logical classification scheme, as illustrated in thefollowing diagram, provides a consistent view of the inventory withoutrequiring the user to understand the inner workings of the inventory's physicalstructure.



In Endevor, the logical attributes, which are used to classify an element,include its location, system, subsystem, and type. These attributes are a directpart of the identification of that element. This eliminates the need to establishadditional libraries, rename elements, or use cryptic naming conventions todefine and maintain a classification scheme. Because these classificationattributes are used in addition to the existing element name, there is no needto rename elements to bring them under the control of the Endevor InventoryManager.

2.1.1.2 Physical Structure

In today's IT environment, the physical requirements of a properly managedinventory have grown beyond the capabilities of older library managementsystems and conventional PDS-based systems. Many library managementsystems are unable to store source that is longer than 80 characters, despite thefact that many modern-day languages do not conform to this format.Conventional PDSs do not restrict record length, but elements of differentrecord lengths must reside in physically separate libraries. Using thesestructures, the only way to keep multiple revisions of an element is to eitherreplicate libraries to hold prior revisions or use a naming convention in whichthe revision is part of the element name.

Physical repository-Endevor's Inventory Manager has the flexibility to managethe physical data sets in which elements are stored, without regard to logicalclassification boundaries or trivial physical differences between the inventoryelements. It can do the follwing:

■ Handle unrestricted source record lengths

■ Store elements of different record lengths in the same repository

■ Store multiple revisions of an element in a single repository

■ Store elements of the same name in the same repository, regardless ofdifferences in logical classification

■ Change the underlying physical library structure without affecting thelogical view of the inventory



Base/Delta-Endevor employs advanced base/delta technology to store theelements within the application inventory. The first time an element is addedinto Endevor, it is stored in its entirety as the base. Subsequent updates to thatelement create records containing only the changes to the element. These deltasare automatically assigned level numbers and stored by Endevor, as shown inthe following illustration:

This method yields substantial savings in storage overhead by providing anefficient means of storing multiple revisions of an element. It also provides awide variety of ways to view change information, including current, historicalor changes only, available online or in hardcopy format. All change displaysidentify what changes were made and by whom, when and why. This isknown as the forward delta format. Reverse delta format processing is similar;however, the delta source is kept in the current format and deltas are used torecreate prior iterations of the source.

2.1.1.3 Interfaces to AllFusion CA-Panvalet and AllFusion CA-Librarian

Interfaces are available that allow Endevor to read directly from and writedirectly to AllFusion CA-Panvalet and AllFusion CA-Librarian files.Additionally, these interfaces allow you to use AllFusion CA-Panvalet andAllFusion CA-Librarian files to contain base/delta source within Endevor. Inthis way, your initial investment in library management systems is enhancedrather than rendered obsolete.


2.2 Change Control

2.2 Change Control

Applications typically undergo extensive modifications as companiescustomize and fine-tune software systems to meet their specific businessrequirements. Given the sheer volume of change requests in today's ITorganization and the growing demand for more effective ways of tracking anddocumenting development change activity, manual change control procedurescan no longer be relied upon to produce the accurate, reliable informationneeded to identify problems, track projects, and analyze the impact of change.

2.2.1 Automated Change ControlEndevor forms an envelope around your application environment and capturesall change events, enabling you to identify what has been changed, who madethe changes, when, and why. And since Endevor performs change controlfunctions automatically, the resulting information is always accurate andup-to-date.

2.2.1.1 Identifying and Tracking Changes

As a prerequisite to understanding, controlling, and auditing the softwareenvironment, change control systems must be able to identify changes as theyoccur, then further pinpoint when the changes were made, by whom, when,and why.

CCIDs-Endevor Change Control Identifiers (CCIDs) provide a means ofgrouping and manipulating similar kinds of change activity. For example, anumber of different elements (COBOL copy members, COBOL programs, andso forth) can be included in a single change request. By tagging each of thosechanges with a common CCID (such as FIX01), every change made for thatchange request is categorized as belonging to that CCID. Subsequently, theCCID can be used to identify and manipulate all the elements within thechange request. For example: Move all elements for COD FIX01 from Unit Testto System Test. CCIDs can also be predefined and validated for changeadministration purposes.

Change History-Endevor automatically captures and dynamically tracks allsource changes by creating a unique delta to record each change event. Anelement's delta levels identify not only the actual lines of code that have beenchanged, but also user, comment, CCID, and date and time information forthat change. The result is a complete and accurate history or audit trail ofapplication change activity.


2.2 Change Control

Regression Notification-In parallel development situations where manyindividuals work on the same module concurrently, change regression occurswhen one individual unintentionally negates (rather than incorporates) thechanges made by another individual. When unchecked, regression can be amajor cause of production failures. During action processing, Endevorperforms a regression check and notifies you when regression has occurred,allowing you to quickly pinpoint and correct the situation before it adverselyaffects the production environment.

Signin, Signout-In order to avoid possible regression during paralleldevelopment, Endevor provides signin/signout security at the element level.This optional capability is enabled on a system-by-system basis. When thefacility is enabled, elements are signed out as they are retrieved. While otherusers can retrieve copies of those signed out elements, they cannot updatethose copies within Endevor without explicitly overriding the original user'ssignout. Only authorized users can exercise the explicit override feature.

Activity Logging-A complete log of all activity within Endevor can be writtento a variety of data structures, including standard SMF records. Thisinformation, available online and in hardcopy format, provides a high levelaudit trail of change events which can be used to determine change patternsover time.

2.2.1.2 CA Endevor Change Manager Interface for IBM's Tivoli InformationManager

Endevor provides a flexible, programmable interface to IBM's TivoliInformation Manager change management product. This interface allowscertain change administration functions to be performed through TivoliInformation Manager on behalf of Endevor. These functions include: thevalidation of CCIDs against the Tivoli Information Manager database; thelogging of Endevor actions to Tivoli Information Manager; the ability to useTivoli Information Manager's approval and notification facilities; the ability tocontrol Endevor actions based on Tivoli Information Manager's CCID statusinformation; and the ability to query and utilize Tivoli Information Manager'schange, problem, and configuration information during Endevor actionprocessing.

2.2.1.3 Automating Processes

In application development, a procedure or process is the set of steps used totransform source language statements into executable code. Some inventoryelements, such as those written in 3rd generation languages (COBOL,Assembler, C, PL/I, and so on) have straightforward processes that compilethe source and link-edit the object. Other element types require more complexprocesses, such as the resolution of data base calls or the automated generationof textual documents. Because these processes ultimately determine how anelement will interact in production, the management of these procedures iscritical.


2.2 Change Control

One of the powerful facilities provided by Endevor involves the regulation andcontrol of all transformation processes through automated procedures calledprocessors. Endevor processors are written in job control language (JCL)statements that specify process steps, parameters, error conditions, data setnames, output libraries and the like. Once defined, processors can be used toautomatically carry out a variety of procedures and create the outputsassociated with application elements. Element types within the inventoryclassification determine the appropriate processors. For instance, elements thatare written in COBOL are typically handled by the COBOL compiler andlinkage editor, while elements that are classified as copy members are usuallyvalidated and copied to a specific location.

Automated Output Generation-Endevor processors are often used to automatethe procedures that generate outputs from source. As illustrated in thefollowing diagram, you can create a processor for Batch COBOL programs thatautomatically performs a COBOL compile and link-edit into the Financesystem's load library, and stores the listing in the Finance system's listinglibrary.


2.2 Change Control

Automated Promotion Procedures-A processor can also contain procedures forpromoting applications throughout the development life cycle. When Endevoris instructed to perform a promotion, it reads the processor definition to obtaindirections about the promotion procedures specified for a selected elementtype. Those procedures are then uniformly invoked by Endevor. Whenpromoting a Batch COBOL program within the Finance system from Testing toProduction, for example, a MOVE processor can be defined which containsinstructions for automatically copying the load modules from the Test loadlibrary to the Production load library.

Automated Backup and Recovery-In addition to automating the proceduresused to generate outputs from source and promote applications throughout thedevelopment life cycle, processors can be defined to execute emergency backupand recovery procedures. For example, a MOVE processor can contain a stepthat automatically copies production load modules to a backup library. Arecovery procedure can additionally be defined to copy that module from thebackup library into an emergency library in the event of a production failure.

2.2.1.4 Establishing Source-to-Executable Synchronization

In order to effectively and accurately maintain, debug, and audit software, youmust be able to link executable code back to its originating source. Endevorachieves this goal by controlling the processes by which outputs are createdfrom the source, and further ensures source-to-executable synchronization byaudit stamping or footprinting those outputs.

Process Control-Endevor's automated processors ensure that thesource-to-executable link is not compromised, by tying the process used tocreate outputs directly to the manipulation of the source. Frequently, loadmodules and their associated source are processed at different points in time,presenting a precarious window in which a change to either one causes anout-of-sync condition. When source is presented to Endevor, the outputs areautomatically created from the current source through the use of automatedprocessors. When source is moved through the development life cycle,Endevor's automated processors ensure that the load modules and outputs aremanipulated together with the source, rather than through separateprocedures.

Footprints-Footprinting is a change control technique employed by Endevor tomaintain synchronization between source and its related executable. Duringelement processing, Endevor places an encrypted audit stamp called afootprint in the output source, object, or load modules that are created. OnlyEndevor automatically builds footprints as an integral part of thesource-to-executable transformation process.


2.2 Change Control

Endevor footprints contain the following information:

■ Location information

■ Element name

■ Element type

■ Element version/level

■ System and subsystem to which the element belongs

■ Date/time the footprint was assigned

Endevor employs standard operating system facilities to store its footprints,thereby ensuring compatibility with present and future operating systems. In aPDS, for example, the footprint is stored in the user data area of the directory;in AllFusion CA-Librarian, as a history record; in AllFusion CA-Panvalet, as acomment field; in a load module, in the user IDR record for the CSECT. Alldata structures managed by Endevor (source libraries, copy libraries,executable libraries, and processor listing libraries) contain footprintedelements. Footprints can be used to validate the source-to-executable link ofan entire load library. And because Endevor footprints uniquely identify theversions/levels of input components, they play a key role in configurationmanagement. The following diagram provides a high-level view of howautomated processors and footprints work together:


2.2 Change Control

As illustrated previously: 1) the source is built from Endevor's internalbase/delta format, and a footprint representing that element's source is createdand made available to subsequent steps in the Endevor processor; 2) the sourceis compiled; 3) the output object from the compile is stamped with a footprintbefore being passed to the next step; 4) the linkage editor links the programinto the appropriate load library; and 5) the listings from the previous stepsare combined and stored (also with a footprint) in the appropriate listinglibrary.

2.2.1.5 Audit Management

As valuable corporate assets, applications cannot be compromised when itcomes to integrity, reliability, and recoverability. For this reason, applicationsmust be controlled and secured in a way that meets stringent auditabilityrequirements. Endevor's automated change control functionality fully satisfiesthe scope of an audit and provides the necessary platform for producingmanagement reports that can be used to evaluate software integrity.

2.2.2 Endevor ActionsEndevor performs software management operations through user-invokedactions, which are available in both foreground (online) and background(batch) modes. These actions are briefly described as follows:

ADD-The action used to introduce an element into an Endevor environment.

ARCHIVE-The action used to copy an element and all of its change historyand control information from an Endevor environment to an external data set.

DELETE-The action used to remove an element from an Endevor environment.

GENERATE-The action used to execute the Endevor automated processor foran element.

LIST-The action used to scan members in a library or the Endevor inventoryto generate a list of elements that meet specific selection criteria.

MOVE-The action used to promote an element from stage to stage within anEndevor environment.

PRINT-The action used to produce hardcopy output of Endevor element,change, and change history information.

RESTORE-The action used to re-introduce an element to Endevor from anarchived data set.


2.2 Change Control

RETRIEVE-The action used to copy any level of the source of an element froman Endevor environment into an external data set.

SIGNIN-The action used to remove the user signout associated with anelement.

TRANSFER-The action used to transport an element from one location toanother, where each location can be either an Endevor location or an externaldata set.

UPDATE-The action used to create a revision of an element in an Endevorenvironment. When applicable, these actions drive the automated processorsthat have been defined to Endevor. Before an action is executed by Endevor, asecurity check confirms the user's authority to perform that action upon therequested element. All actions and their results are reflected in Endevorexecution processing reports. Additionally, all Endevor activity (transactions)may be recorded using SMF.

2.2.3 Endevor's Software Control Language (SCL)The tedious and repetitive tasks associated with manipulating the softwareinventory are time-consuming and prone to error. Endevor's Software ControlLanguage (SCL) is a powerful yet simple language which, when combinedwith Endevor actions, eases the burden of manipulating and moving portionsof the software inventory throughout the entire development life cycle.

SCL Capabilities: SCL saves substantial amounts of time by enabling you towork with as many (or as few) Endevor actions as are required to complete aspecific job. With SCL, you can do the following:

■ Perform bulk data manipulation.

■ Set up a single list or multiple lists of actions for manipulation by Endevor.

■ Establish standardized global settings for action requests.

■ Process actions in inventory type sequence order, automatically sortingelements according to specification.

■ Generate software configuration lists based on different selection criteria.

■ Use a single scan facility that will run against AllFusion CA-Panvalet,AllFusion CA-Librarian, a PDS, and Endevor, eliminating the need to useseparate utilities to scan source code.

■ For problem-solving purposes, generate a list of only those elements thatwere not successfully processed at a specific time.

■ Write user-defined front-ends for various vendor-supplied programs.

■ Integrate Endevor into existing job scheduling systems.


2.2 Change Control

SCL can be generated and manipulated through online screens, providing aneasy-to-use, flexible environment for executing software procedures. UsingSCL, repetitive tasks, which normally require significant amounts of time, canbe accomplished with very little effort.


2.3 Configuration Management


Historically, a major deficiency in the management of software systems hasbeen the lack of an accurate means of determining the interdependencies orconfigurations of applications and their related components. Semi-automatedsource scanning techniques have provided a partial solution. These techniquesare no longer feasible, however, given the size and complexity of today'sapplications, the frequency of component changes, and the growing demandfor a more auditable means of tracking and managing software configurationsas they evolve over time.

2.3.1 CA Endevor Change Manager Automated ConfigurationOption

Built upon a logical inventory structure and a powerful change controlplatform, Endevor provides an automated configuration management facility(ACM) that monitors and establishes accurate configuration information.

2.3.1.1 Defining Software Configurations

When a program or module is translated from source to executable, all of itsrelated components are collected from their resident libraries (copylibs,maclibs, and so forth). In order to keep an accurate record of changingsoftware configurations, the process of tracking program-componentrelationships and associated change activity must be performed automaticallyas an integral part of the translation procedure.



The Component Monitor-While a program or module is being translated by aprocessor, ACM automatically captures the program-component relationshipsas they are resolved from the selected data sets, as the illustration shows:



The Component List-As output from the translation procedure, ACMautomatically produces a snapshot or Component List for each monitoredprogram. This Component List is an internal data structure that preserves aphysical profile of the configuration. As illustrated next, the Component Listidentifies all input program components and where they originated, as well asthe output components created as the result of the translation procedure.Footprint information, including the version and level of the component, isalso noted, if present.

ConfigurationType

Name FootprintInformation

Step Library

Element PROGRAM X v1.3

Processor Record COMPLINK v1.8

Input COPYRECA v2.1 Compile COPYLIB1

Input COPYRECB v2.5 Compile COPYLIB2

Output PROGRAM X v1.3 Compile OBJLIB

Output PROGRAM X v1.3 Link-Edit LOADLIB

The element information describes the program being generated. Theprocessor information describes the Endevor processor used to generate theelement. The input components identify the component items referenced andany footprints that exist in the monitored data set. The output componentsidentify the elements that were created during processor execution.

Storing Component Lists-The first time a Component List is created, it isstored in its entirety as the base. Subsequent differences in Component Listsfrom one program translation to the next are stored as deltas (changes only)and automatically assigned a component level number. By using base/deltatechnology to store Component Lists, ACM enables you to comparecomponent changes from compile to compile, a capability unavailable throughsource scanning techniques.

Viewing Component Lists-When stored over time, Component Listinformation becomes the basis for maintaining and viewing component history.Through online displays, ACM lets you view Component List informationfrom four perspectives: 1) summary of component levels, 2) current level of acomponent, 3) component changes, and 4) component history.



2.3.1.2 Using Software Configurations

Using the information contained within Component Lists, it is possible tocreate a selection list. In the following diagram, a selection list has been createdby using Endevor to LIST all programs WHERE COMPONENTS EQUAL'COPYRECA':

As a powerful cross-reference facility, the LIST action, in combination withselection lists in SCL format, provides the necessary foundation for performinga number of essential configuration management functions.

Propagating Component Changes to Related Programs- When a component ischanged, it is necessary to propagate those changes to all affected programs.Using the LIST action, you can perform change impact analysis by identifyingevery program containing that changed component. And you can also use theresulting selection list to perform bulk data manipulation by re-compilingthose programs, all at the same time, to reflect the change.

Validating a System for Consistent Use of Components - In order to preventproduction failures, it is desirable to validate that all programs are using thecorrect component versions/levels. Execution reports from LIST actionexecution, in combination with selection lists, can be used to identifyinconsistencies.



Re-Creating Past Configurations-It is sometimes necessary to recreate aprogram exactly as it has existed at a past point in time. Using the LIST action,you can recreate an older version/level of a program's load module thatincludes the old versions/levels of all related components used at thedate/time the load module was originally created.


2.4 Component Validation

2.4 Component Validation

Component validation provides the assurance, prior to a promotion, that alldependencies such as Copy Member, Include Member, macros, and so on areincluded in the promotion and that all programs have been compiled with thecurrent iteration of the copy members.


2.5 Release Management


Release management activities revolve around identifying and distributingsoftware releases. Depending on the circumstances, a "release" can consist ofthe elements changed during a maintenance effort, or it can represent an entirecross-section of the software inventory. Distribution of a release can be assimple as promoting a change into production, or as complicated as managingmultiple concurrent releases of entire software systems. Accurate andup-to-date information is a prerequisite for performing every task, fromcreating a list of exactly what is to be released to verifying that the release wassuccessfully accomplished. This kind of information can only be obtainedthrough an automated, integrated release management system.

2.5.1 Automated Release ManagementIn many installations, production turnover and release management areperformed, often manually, as discrete activities by separate groups. Problemsarise when software release packages are created manually "on paper," wherethere is a chance that the contents are incomplete or inadvertently changedprior to or during execution. Endevor provides integrated, automated releasemanagement functionality, ensuring that software release packages are built ona solid inventory management structure, created using automated techniques,and implemented as an integral part of the release process. In addition,Endevor's change administration facility provides online release packageapproval capabilities. Only with these combined capabilities is it possible toaccurately create and manipulate a software release, perform change impactanalyses, and track changes from release to release.

2.5.1.1 Change Administration

Endevor provides change administration, in addition to security, as a means ofspecifically organizing and controlling change to portions of the softwareinventory. Through the Endevor change administration facilities, it is possibleto provide authorization capabilities to the person(s) responsible for portions ofthe software inventory.

Approver Groups-Endevor establishes change administration authorizationthrough the definition of approver groups (named groups of user IDs) and thesubsequent relation of those approver groups to portions of the Endevorinventory. For example, within the Payroll subsystem of the Finance system,you could establish an approver group that approves or denies changes to allelements within that system and subsystem. Some of the users within thegroup could be required to approve changes while the approval of other userswould be optional. A quorum or minimum required number of approvers canbe established for any approver group. "EMERGENCY" approver groups canbe established consisting of those user IDs which must authorize emergencyfixes to a portion of the inventory.



Change Packages-Authorized users build change packages, which containEndevor action requests. The user specifies whether the handling of thatchange package will be defined as 'STANDARD' or 'EMERGENCY'. The useralso defines a date/time window within which the change package can beexecuted. Once the change package is built, it is then CAST, a process whichcauses Endevor to prepare the package for subsequent approval processing.Endevor automatically builds the list of approvers for a change package basedon the previously defined approver groups. The change package then goesthrough approval processing, followed eventually by execution.

2.5.1.2 How It Works

Building a Change Package-Authorized users build change packagesconsisting of any number of Endevor action requests. Change packages can bebuilt from online screens, imported from outside data sets and/or copied fromexisting packages. They can be edited, modified and/or appended to at anypoint during the build process.

Preparing a Change Package for Review-The change package is CAST. Theprocess of casting a change package causes the approvers for that package tobe built based on the previously defined approver groups. Once a package isCAST, it can no longer be modified.

Reviewing a Change Package-Users in the approver group(s) associated witha package can approve or deny the change package. Required users mustprovide their approval. Once all required approvals have been made, and theestablished quorum of approvals has been met, the change package can beexecuted.

Executing a Change Package-At execution time, Endevor validates that allapprovals have been made and that none of the elements have changedbetween the time the change package was CAST and when it was executed.Endevor also validates that the change package is being executed within thedate/time window established when the change package was built. Endevorthen executes all of the actions in the change package. Checkpoint/restartfacilities are available so that change packages that fail execution can bere-executed properly. Change packages can be executed online or in batch.

Automatic Package Backout-Subsequent to execution, it is possible to quicklyand easily back out a change package. BACKOUT has the effect of reversingany outputs created by the execution of that package to the state they were inprior to package execution. BACKIN reverses the process.



2.5.1.3 Managing Production Turnover

Using the Component Lists created by Endevor's Automated ConfigurationManager in combination with Endevor's logical inventory structure, you canbuild a change package containing all of the programs and components thatmake up a maintenance release. Once the package has been built, it can beused to drive production turnover for that maintenance release.

Creating a Maintenance Change Package-When Change Control Identifiers(CCIDs) are used to tag all of the changes which make up a maintenancerelease, those CCIDs can be used as selection criteria to produce a package thatitemizes all of the elements which comprise that maintenance release, as wellas all related element components. For example, you could build a packagethat contains MOVE commands for all of the elements changed for CCID'FIX01' as well as all the input components for those elements.

Promoting a Maintenance Release-Once the change package has beenconstructed and has gone through the appropriate approvals, it can be used toperform the production turnover. In our example, execution of the ' FIX01'change package will automatically perform production turnover, promoting allof the elements contained in the package, as illustrated in the followingdiagram:

2.5.1.4 Managing Software Releases

Endevor's powerful inventory structure, together with ACM's ComponentLists, can be used to manage all aspects of releasing software . Once a changepackage has been generated, its contents can be used to drive the distributionof the software release, track changes from release to release, and recreateprevious releases.



Creating a Software Release Package-The inventory management structure ofEndevor and the configuration information created by ACM can be used tocreate complete, reliable, and reusable software release packages. For example,a complete release package could be built containing all of the elements inRelease 2 of the Finance system, and all of the components belonging to thoseelements. The resulting package would contain not only all of the elementsthat comprise the software release at this point in time, but information aboutthe current versions and levels of those elements.

Release Distribution-Once a release package has been constructed, it can beused to drive the distribution process, regardless of whether the software is tobe moved to another Endevor location in-house, transferred to anotherEndevor location at a remote machine or site, or distributed to external files,perhaps for shipping to customers or divisions. In our example, the contents ofthe package created previously are used to drive the TRANSFER of Release 2of the Finance system from Site 1 to Site 2, as illustrated in the followingdiagram:

Using the contents of release packages to drive the distribution processprovides the added advantage of automating both the distribution process andthe documentation of that process.



2.5.1.5 Release to Release Comparison

An important aspect of any type of release management system is its ability totrack changes from release to release. This broad, system-wide perspective isnecessary when managing multiple software releases. Packages are kept insuch a way that once created, their contents can be used in a number of ways.They can be compared to find out exactly what has changed from one releaseto the next. If the contents of the package are extracted and stored in Endevor'sbase/delta format, it is also possible to view changes to a software system overtime. This capability is especially useful when trying to identify whichmodules of a software system have been added, removed, or changed prior todistributing a partial release consisting of changed components only.


2.6 Supporting Functionality


In addition to its inventory management, change control, configurationmanagement, and release management facilities, Endevor provides capabilitiesin the areas of parallel development management, software securitymanagement, and software information management. This broad range ofproduct functionality is designed to support the entire software managementlife cycle, not just one aspect.

2.6.1 CA Endevor Change Manager Parallel Development OptionEndevor provides parallel development management capabilities through theCA Endevor Change Manager Parallel Development Option (PDM). Using thispowerful development tool, it is possible to create a merged program from thecomparison of a base program and two independently modified versions ofthat base program. By eliminating many of the time-consuming, manual tasksassociated with merging parallel development updates, PDM saves time andreduces the margin for error. PDM also provides a means of identifying andresolving conflicts before merging program updates. For this reason, PDM is anecessary tool for effectively managing concurrent application developmentand resolving problems which arise when integrating in-house modificationswith vendor updates.

2.6.1.1 Managing Parallel Development Activities

When several programmers work on the same module concurrently, there isalways the danger that some modifications will be overridden by others or willbe in direct conflict with one another. Beyond the basic frustration factor, thisproblem can have serious consequences from a control and maintenancestandpoint.



2.6.1.2 Managing Vendor Updates

Purchased software packages are typically customized to meet in-housedemands. Unless those modifications are painstakingly documented, problemsarise when an update arrives from the vendor. What exactly was changedin-house? And what modules did the vendor change, add, or delete? Manualmethods for resolving these conflicts are time-consuming and error-prone,underlining the need for automated solutions for merging vendor updates within-house modifications, and reconciling changes from release to release.

2.6.1.3 Basic PDM Operation

The following diagram provides a simple illustration of how PDM operates:

In Step 1, the Work-in-Process (WIP) file is created and statistics are reported.In Step 2, the WIP file is edited. In Step 3, the merged member is built.

Building the WIP File-The first step in using the Parallel DevelopmentManager is to build a Work-in-Process (WIP) file. The WIP file is a PDSstructure which combines three source files: the Root, Derivation 1, andDerivation 2. As an example, if PDM is being used to manage a vendorupdate, the Root would be the source for the old release, Derivation 1 wouldbe the source for the in-house modifications made to that old release, andDerivation 2 would be the source for the vendor's new release. As the sourceinput files are being compared to produce a WIP File, statistics are generated.These statistics reveal critical information about the source comparison, such asthe number of inserts and deletes per module, the percentage of the modulethat has changed, and the number of simultaneous (and potentially conflicting)updates.



Editing the WIP File-With statistics in hand, it is now possible to view andedit the members which contain conflicts. At this point, you can decide whichconflicts to resolve and how to resolve them.

Creating Merged Source-Once you have viewed and edited the WIP file toyour satisfaction, you can use PDM to automatically merge the WIP sourceinto an output source library. This output source is then ready for compilationor, if applicable, introduction into Endevor. The Parallel DevelopmentManager can be used in both online and batch modes, and can operate on amember-by-member basis on a list of members, or on any portion of theEndevor inventory.

2.6.2 Software Security ManagementTraditionally, inventory security has been provided at the physical file levelbut not at the individual element level. Endevor security is based on itsinventory structure, enabling security rules to be defined according to thatstructure, at the system, subsystem, type, and element levels. Additionally,Endevor actions are secured, providing a means of restricting individuals tothe appropriate change control functions at specific stages within the softwaredevelopment life cycle.

2.6.2.1 Native Security

Endevor native security provides protection against unauthorized access andprocessing through three tables: Access Security, User Security, and ResourceSecurity. The Access Security Table defines the environments to which eachuser has access. The User Security Table defines the systems/subsystemswithin a particular environment and the level of activity for which each user ispermitted access (display only, delete, add, and so on). The Resource SecurityTable defines any element naming conventions that are restricted to aparticular system/subsystem and the Endevor actions for which the restrictionapplies. The use of Endevor native security is optional and is enabled only ifone or more of these tables is defined. When defined, access is permitted onlythrough these tables.



2.6.2.2 CA Endevor Change Manager Interface for External Security

In addition to native security, Endevor provides the CA Endevor ChangeManager Interface for External Security (Endevor ESI). With Endevor ESI,installations which currently use eTrust CA-ACF2 Security, eTrust CA-TopSecret Security, or RACF security systems can secure access to Endevorfunctions and data sets through those centralized systems rather than locallythrough Endevor security tables. Endevor ESI accomplishes this through aninterface to IBM's System Authorization Facility (SAF). As illustrated in thefollowing diagram, Endevor ESI replaces standard Endevor security tables withan SAF interface module:

With Endevor ESI in place, each security request is checked through thecentralized security system in order to validate access to Endevorenvironments, menu options, and actions against inventory elements.

2.6.3 Software Information ManagementThrough a combination of its master inventory data base (Master Control File)and SMF log file, which notes every change attempted and completed, as wellas security violation information, Endevor provides extensive display andreporting facilities. The resulting information provides managers with anaccurate and reliable means of performing workflow analysis, project tracking,trouble-shooting, and audit management.



2.6.3.1 Displays

Endevor provides extensive display capabilities for viewing status and changeinformation online. The following displays can also be printed in hardcopyformat:

■ Element Master Control File Information

■ Element Change Summary

■ Element Change History

■ Element Changes

■ Element Browse

■ Component Summary

■ Component History

■ Component Changes

■ Component Browse

■ Footprint Display

2.6.3.2 Reports

Endevor provides four types of reports: Master Control File, Historical,Footprint, and Change Administration.

Master Control File Reports-The following reports reflect the definitions ofsystems, subsystems, element types, and elements, as specified to the EndevorMaster Control File:

■ System Inventory Profile

■ System Inventory Summary

■ Element Catalog

■ Element Activity Profile

■ Element Activity Summary

■ Element Catalog by CCID

■ System Definition Profile

■ Element Signed Out Profile-By System

■ Element Signed Out Profile-By User

■ Approver Group Definition

■ Approver Group Usage



Historical Reports-The following reports summarize security violations andelement activity as recorded by Endevor:

■ Security Violation Profile

■ Security Violation Summary

■ Element Activity Profile

■ Element Activity Summary

Footprint Reports-The following reports document footprint informationplaced in source and load modules by Endevor:

■ Library Member Footprint Report

■ Library CSECT Listing

■ Library ZAPped CSECT Report

■ Footprint Exception Report

Change Administration Reports- The following reports document changepackage activity:

■ Package Detail Reports

■ Package Summary Report

2.6.4 Endevor Benefit SummaryBased on advanced change control technology which is implemented throughan automated, integrated approach, Endevor yields a number of substantialbenefits by doing the following:

■ Providing extensive inventory management capabilities whichaccommodate all source and executable code, regardless of type or recordlength.

■ Providing a means of categorizing, viewing and manipulating physicalinventory components as they relate to logical workgroups.

■ Creating an unbreakable audit trail of all change events for purposes ofhistorical analysis and auditing.

■ Capturing and storing all change information using advanced,space-saving base/delta storage techniques.

■ Assuring an inviolate link between executable code and its originatingsource.

■ Enforcing standard, consistent change processes.

■ Providing an accurate means of creating and tracking softwareconfigurations.

■ Automating the movement of entire software release packages throughoutthe development life cycle.



■ Providing additional approval and notification capabilities through changeadministration functionality.

■ Extending security to the inventory member level.

■ Providing a means to compare and implement vendor application updates.


Chapter 3. Defining Inventory Structures

This chapter describes how to define Endevor inventory structure. It containsthe following sections:

■ Basic Panel Flow

■ Displaying Site Information

■ Displaying Stage Information

■ Defining Systems

■ Cloning System, Subsystem, and Type Definitions

■ Defining Subsystems

■ Defining Types

■ Defining the Type Processing Sequence

■ Updating Type Data Set Definitions

■ Displaying Environment Information

Chapter 3. Defining Inventory Structures 3-1

3.1 Basic Panel Flow


This section introduces the basic panels involved in displaying environmentand stage information, and defining and maintaining system, subsystem, andtype definitions. (If you want to perform these tasks in batch, see the chapter“Environment Definition SCL” in the SCL Reference Guide for the appropriateSCL commands.)

1. Begin by invoking Endevor, as described in the User Guide. If you haveaccess to multiple environments, Endevor first displays the EnvironmentSelection panel, shown next:

� �------------------------ Endevor Environment Selection ------- Row 1 to 2 of 2

Option ===> 1 Scroll ===> CSR

Select an environment to continue. Enter the END command to exit.

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

1 SMPLTEST SAMPLE TEST ENVIRONMENT

2 SMPLPROD SAMPLE PRODUCTION ENVIRONMENT

�� Bottom of data ��

� �

2. Select the environment you want by typing its number in the OPTIONfield, and pressing Enter. Endevor displays the Endevor Primary OptionsPanel, shown next:

� � --------------------- Endevor Primary Options Panel ---------------------

Option ===> 4

� DEFAULTS - Specify Endevor ISPF default parameters

1 DISPLAY - Perform Display functions

2 FOREGROUND - Execute Foreground Actions

3 BATCH - Perform Batch Action processing

4 ENVIRONMENT - Define or Modify Environment information

5 PACKAGE - Perform Foreground Package processing

6 BATCH PACKAGE - Perform Batch Package SCL Generation

U USER MENU - Display user option menu

T TUTORIAL - Display information about Endevor

C CHANGES - Display summary of changes for this release of Endevor

X EXIT - Exit the Endevor dialog

Current environment: SMPLTEST

Use the EXIT option to terminate Endevor

� �



3. Select option 4 (ENVIRONMENT) on the CA Endevor Primary OptionsPanel, and press Enter. Endevor displays the Environment Options Menu,shown next:

� �------------------------ ENVIRONMENT OPTIONS MENU ---------------------------

OPTION ===>

1 SITE - Display site information

2 STAGE - Display stage information

3 SYSTEM - Display, delete, create, update or clone system

4 SUBSYSTEM - Display, delete, create or update subsystem

5 TYPE - Display, delete, create or update type definitions

6 PROCESSOR GROUP - Display, delete, create or update processor groups

7 TYPE SEQUENCE - Display or update type processing sequence

8 DATA SET - Display or update type data sets

9 APPROVER GROUP - Display, delete, create or update approver groups

A RELATE GROUP - Relate approver groups to systems, subsystems, etc.

D DESTINATION - Display, delete, create or update shipment destinations

E ENVIRONMENT - Display information about the current environment

S SITE SYMBOLS - Display site symbol definitions

� �

4. To select an option, type the appropriate number or letter (1-9, A, D, E, orS ) in the Option field, press Enter. Endevor displays the subfunctionpanel for the option requested.

5. When you are through, return to the CA Endevor Primary Options Panelby pressing END repeatedly. To return to the invoking facility (ISPF orTSO) from the Endevor Primary Options Panel, press End, or type END inthe Option field, and press Enter.

Note: This Environment Options Menu shows that the Global TypeSequencing option is not in effect. If the Global Type Sequencing option isenabled at your site, the description on the Environment Options Menu foroption 7 TYPE SEQUENCE appears differently than if it is not in effect. WhenGlobal Type Sequencing is not in effect, type sequencing can be viewed andupdated through the Environment Options Menu. When Global TypeSequencing is in effect, the Type Sequencing can be viewed, but not updatedthrough the Environment Options Menu. For details, see Global TypeSequencing in the chapter “Displaying Endevor Information” in the User Guide.



3.1.1 The Environment Options MenuThe options for the Environment Options menu are summarized next. Options1-5, 7, 8, and E are discussed in more detail later in this chapter. Option S isdiscussed in Chapter 7, “Site Symbolics.” Option 6 is covered in the ExtendedProcessors Guide. Options 9, A, and D, are discussed in the Packages Guide.

Use this option To

1 Display site definitions, as specified in the EndevorDefaults Table.

2 Display the two stage definitions for an environment.

3 Display, delete, create, update, or clone (copy) thedefinition and/or mapping of a system.

4 Display, delete, create, or update the definitionand/or mapping of a subsystem.

5 Display, delete, create, or update the definitionand/or mapping of a type.

6 Display, delete, create, or update the definitionand/or mapping of a processor group.

7 Display or update the relative sequence of executionfor Endevor actions, for all element types defined to aparticular system. If the optional feature Global TypeSequencing is enabled at your site, you cannot updatethe type processing sequence through theEnvironment Options Menu.

8 Change the data sets defined for use with a specificsystem.

9 Display, delete, create, or update approver groups.

A Establish relationships between approver groups andinventory areas within an environment.

D Display, delete, create, or update destinations forpackage shipments.

E Display environment definitions, as specified in theEndevor Defaults Table.

S Display the site symbolics table. The table isspecified in the C1DEFLTS table.



3.1.2 Request and Selection PanelsEndevor provides request and selection panels to help you identify systems,subsystems, and types to work on when you do not know their full name.

Request panels are the first panels that appear when you select options 3 - 9and A on the Environment Options Menu. Request panels look like this:

� �----------------------------- TYPE REQUEST ----------------------------------

OPTION ===>

blank - Display type definition

# - Delete type definition

C - Create type definition

U - Update type definition

ENVIRONMENT ===> SMPLTEST

SYSTEM ===>

TYPE ===>

STAGE ===> T T - TEST Q - QA

� �

You use these panels to request a particular function (display, delete, create, orupdate), and to identify the particular system, subsystem, or type againstwhich you want to perform the function.

Selection List panels appear after request panels when you provide namemasks in any of the fields on the request panel. Selection List panels look likethis:

� � -------------------------- SYSTEM SELECTION LIST ----------- ROW 1 OF 2

COMMAND ===> SCROLL ===> CSR

CURRENT ENV: SMPLTEST

NEXT ENV: SMPLPROD

SYSTEM SYSTEM TITLE

ADMIN ENDEVOR ADMINISTRATION SYSTEM

FINANCE FINANCIAL SYSTEM

�� BOTTOM OF DATA��

� �



Selection List panels allow you to select a system, subsystem, or type fordisplay, update, or deletion. From this panel, you can display an item byplacing an S to the left of the listed name. On some selection panels, you canperform the following actions:

■ Delete an item by placing a # to the left of the listed name.

■ Update an item by placing a U to the left of the listed name.

When you press Enter after making one or more selections from a selectionlist, Endevor displays the definition panel for the selected items, with therequested mode (Display, Delete, or Update) in the upper left corner of thepanel.


3.2 Displaying Site Information


This section describes how to display site information.

3.2.1 Site Information PanelTo display information specific to the current site (as coded in the DefaultsTable), select option 1 on the Environment Options Menu, and press Enter.Endevor displays the Site Information panel.

� � ---------------------- Site Information from C1DEFLTS -------------------------

Command ===>

Customer Name..... SUPPORT R7

------------------ Function Controls -------------------- - Options -

Site ID........... � Access Table...... BC1TNEQU ACM...... N

Release........... B7��C SMF Record Number. 222 DB2...... N

Environments...... 1 Library System.... LB QuickEdit Y

Userid Start...... 1 Library Program... IEFBR14 ESI...... N

Userid Length..... 7 VIO Unit.......... VIO INFO..... N

Batch ID.......... � Work Unit......... SYSDA LIBENV... N

SPFEDIT QNAME..... SPFEDIT Work Volser....... NETMAN... N

SYSIEWL QNAME..... SYSIEWLP Lines per Page.... 6� PDM...... N

Authorized Tables. IGNORE MODHLI............ PROC..... N

Gen in place/SO... Y Signout on fetch.. Y

CA-LSERV JRNL SBS. Mixed Format...... (NONE)

PITR Journal Grp..

SYMBOLICS Table...

(Press Enter for Next Panel)

� �

� �-------------------------- Package Processing Options --------------------------

Approval Reqd....Y CAST Security.....N Security..ESI

Foreground Exec..Y Comp Validation...O

Generated High-lvl Index for Remote PKG JCL........ ENDEVOR

------------------------------- Control Data sets ------------------------------

Element Catalog...................CA.ENDEVOR.ELMCATL

Package Control File..............CA.ENDEVOR.VSAMRLS.PACKAGE

Endevor Macro Library.............CA.ENDEVOR.MACLIB

CCID Validation Data Set..........

ACM Query Root Data Set...........CA.ENDEVOR.ACMROOT

ACM Query Xref Data Set...........CA.ENDEVOR.ACMXREF

------------------------ Endevor Parmlib Information -------------------

Endevor Parmlib Data Set... BST.ENDEVOR.PARMLIB

Type Sequence Mbr...... ETYPESEQ


� �



� �

----------------------------- CA-7 Interface Values ----------------------------

CA-7 Region CCI Node Name.........TSONODE

JCL Data Set Index Seq Nbr........

JCL Data Set Index Symbol.........&ENDEVOR

JCL Data Set Name.................CA7.ENDEVOR.JCLLIB


� �

When you are through reviewing this display panel, press End to return to theEnvironment Options Menu.

3.2.2 Site Information Panel FieldsThis section describes the panel fields.

3.2.2.1 Customer Name Field

Your company name appears at the top of this screen.

3.2.2.2 Function Controls Fields

The following table describes the Function Controls fields:

Field Description

Site ID ID assigned to the current site.

Release Volume serial number of the installation tape.

Environments Number of environments defined at the current site.

Userid Start First position within a user ID that is compared forownership (that is, for signout and override signoutprocessing). This field is used when the USERIDBATCHID field is 0 (JOBNAME).

Userid Length Length of the user ID that is compared forownership. This field is used with the USERIDSTART field when the USERID BATCHID field is 0(JOBNAME).



Field Description

Batch ID Where the user ID associated with a batch job isextracted:

■ 0 — From the JOBNAME; the user ID is checkedfor validity using the userid start and lengthparameters as established previously.

■ 1 — From the USER parameter specified on thejob card submitted with the job. If no USERparameter is defined, you receive an errormessage.

■ 2 — From the USER parameter if it is specifiedon the jobcard or, if no USER parameter has beenspecified, from the JOBNAME. The user ID isvalidated using the user ID start and lengthparameters as established above.

SPFEDIT QNAME Queue name used when Endevor issues an enqueueon a sequential or partitioned data set (notRECFM=U), to prevent simultaneous update to thatdata set. The data set may be a source library, objectlibrary, or other user library. The resource name forthe enqueue is the data set name.

SYSIEWL QNAME Queue name used when Endevor issues an enqueueon a PDS defined with RECFM=U (for example, aload library), to prevent simultaneous update to thatPDS. The resource name for the enqueue is the dataset name.

Authorized Tables Indicates whether Endevor's security tables have tobe loaded from authorized libraries. Values are:

■ Require — authorized libraries are required.■ Allow — unauthorized libraries are allowed, but

Endevor issues a warning message.■ Ignore — Endevor does not check the library's

authorization.

Gen in place/SO Indicates, on a site level, whether Endevor is toperform a Generate in-place with or without signout.

■ Y — An element is signed out to the user whoperforms a Generate in-place action. This is thedefault.

■ N — An element retains its signout setting.Endevor will not sign out an element to a userwho performs a Generate in-place action.



Field Description

CA-L-Serv JRNL SBS The subsystem name associated with the L-Servaddress space. This field must be specified if L-Servis used to control one or more Endevor control filesand the default L-Serv subsystem name is not used.

PITR Journal Grp An L-Serv journal group ID that relates the packagedata set named in this macro to a specific set ofL-Serv journal files. Specification of this parameterenables journaling of changes to Master Control Filesand the Package Control File. The format is:(gggg,nnnn)Where:

ggggThe journal group ID associated with the packagejournal files.

nnnnThe journal group subsystem ID. For moreinformation, see the Utilities Guide.

SYMBOLICS Table Name of a load module containing the site symboldefinition table created by the user.

Access Table Name of the Access Security Table currently in use(applicable for native security).

SMF Record Number Record number assigned to SMF records written outby Endevor.

Library System Indicates the library management system at your site:

■ LB — AllFusion CA-Librarian and PDS■ PV — AllFusion CA-Panvalet and PDS■ blank — OS/PDS only

Library Program Applicable only if your library management system isAllFusion CA-Librarian (LB). This entry indicates thename of the AllFusion CA-Librarian load module foryour site.

VIO Unit Symbolic device name for temporary disk data setsthat are stored on a virtual I/O unit.

Work Unit Symbolic device name for temporary disk data setsthat are not stored on a virtual I/O unit.

Work Volser Volume serial number of the disk used to storetemporary data sets.

Lines per page Number of lines printed per page, for reportsgenerated by Endevor.



Field Description

MODHLI Allows you to assign a prefix other than SYSyyddd toa temporary data set, creating a pseudo-temporarydata set. This applies to temporary data sets that areallocated DISP=MOD at any step in a processor only.Regular temporary data sets, which are notDISP=MOD, use the standard z/OS temporary dataset name. This prefix appears as the first node of thedata set name.

The value specified is a high-level qualifier, which allEndevor users are authorized to use when allocating,deleting, and opening files for output.

The effective name generated is:modhli.Dyyddd.Thhmmss.RA0.jobname.ddname

Where:

modhliThe data specified in the MODHLI operand

yydddJulian date

hhmmssTime in hours, minutes, and seconds

jobnameSame value as jobname

ddnameDDname specified in the processor

RA0 is used instead of RA000 to accommodate 8-byteMODHLI and 8-byte DDnames.

If MODHLI is not specified in the Defaults Table, theeffective name is:SYSyyddd.Thhmmss.RA0.jobname.ddname

Signout on fetch Indicates if the fetched element is signed out to you.Valid values are:

■ Y — The element is signed out when it is fetched,unless it is currently signed out by another user.

■ N — The element is not signed out.

This value affects Add (Fetch), Generate (Copyback),Move (Fetch), Transfer (Fetch), Search and Replace(Fetch) and Quick-Edit.



Field Description

Mixed Format Indicates whether Endevor accepts mixed-case entriesin CCID, COMMENT, and DESCRIPTION fields.Values are:

■ CCID — accept mixed-case in CCID fields.■ Comment — accept mixed-case in COMMENT

fields.■ Description — accept mixed-case in

DESCRIPTION fields.■ All — accept mixed-case in all three fields.■ None — do not accept mixed-case in any field.

3.2.2.3 Options Fields

The information coded in this section indicates whether you have additionalEndevor facilities (such as ACM or ESI) in use at your site at this time. Thefollowing table describes the Options fields. These fields are display-onlyfields.

Field Description

ASCM Indicates if the Endevor ACM facility is installed: Yor N

DB2 Indicates if the Endevor for DB2 facility is installed: Yor N

ESI Indicates if the Endevor ESI facility is installed: Y orN

INFO Indicates if the Endevor Information/ManagementInterface facility is installed: Y or N

LIBENV Indicates if you have the ability to use AllFusionCA-Librarian or AllFusion CA-Panvalet withEndevor: Y or N

NETMAN Indicates if the Endevor Netman Interface facility isinstalled: Y or N

PDM Indicates if the Endevor Parallel DevelopmentManager (PDM) facility is installed: Y or N

PROC Indicates if you have the ability to run processors atyour site: Y or N

Note:

Y — YesN — No



3.2.2.4 Package Processing Fields

The following table describes the Package Processing fields. These fields aredisplay-only fields.

Field Description

ApprovalReqd Indicates whether packages must be approved: Y orN

Foreground Exec Indicates whether packages may be executed inforeground.

Generated High-lvlIndex for RemotePKG JCL

The data set name used for remote packageshipments.

Cast Security Indicates whether to check security authorizations forevery action in a package for the user ID requestingpackage cast: Y or N

Comp Validation Indicates whether component validation is enabledfor packages. Values are:

■ Y — validation is required.■ O — validation is optional.■ W — validation is optional, but Endevor

generates a warning if it is not selected.



Field Description

Security Indicates the type of security controlling the packageoptions.

APPROVER — The site is restricting packageactions to package approvers.ESI — The site is controlling package optionsthrough an external security package such aseTrust CA-ACF2, eTrust CA-Top Secret, or IBMRACF using the ESI interface.MIGRATE — The site is in transition betweenApprover security and ESI security. Both arechecked.

CAUTION:The approver security rules supersede the ESI

security rules. If the user is granted access to thepackage by the approver rules, ESI is not invoked.ESI is invoked only when the user does not belongto any approver groups associated with the package.If there are no approver groups associated with thepackage no access restrictions apply. This occurswith ALL packages before they are CAST.

Note:

Y — YesN — No

3.2.2.5 Control Data Set Names Fields

These fields are display-only fields and are described in the following table:

Field Description

Element Catalog Name of the file containing the element catalog. Formore information, see 1.4, “CA Endevor Libraries” onpage 1-15.

Package Control File Identifies the data set used in this environment tostore packages.

Endevor MacroLibrary

Data set name of the source library established forthis site during installation. This is the library thatcontains the Endevor macros.

CCID ValidationData Set

Data set name of the sequential file containing thedefinitions of the valid CCIDs established for thissite. This field is blank if CCID validation is not inuse.



Field Description

ACM Query RootData Set

The name of the VSAM file your site uses to store thename of each Endevor element and all its relatedcomponents. The recommended name isuprfx.uqual.ACMROOT.

ACM Query XrefData Set

The name of the VSAM file your site uses to store thename of each Endevor component relationship. Therecommended name is uprfx.uqual.ACMROOT.

3.2.2.6 Endevor Parmlib Information

The following table describes the Endevor Paramlib Information fields. Thesefields are display-only fields.

Field Description

Endevor ParmlibData Set

Data set name of the library, which contains the TypeSequence Member.

Type Sequence Mbr The name of the file that defines the processing orderfor Global Type Sequencing.

3.2.2.7 CA-7 Data Set Name Fields

The following table describes the CA-7 Data Set Name fields. These fields aredisplay-only fields.

Field Description

CA-7 Region CCINodename

CCI Nodename assigned to the CA-7 address space.

JCL Data Set IndexNumber

Sequence number associated with the CA-7DEMAND JCL library.

JCL Data Set IndexSymbol

Symbol associated with the CA-7 DEMAND JCLlibrary.

JCL Data Set Name Data Set name of the CA-7 JCL DEMAND library.


3.3 Displaying Stage Information


This section describes how to display the stage information.

3.3.1 Stage Information PanelTo display the definitions of the two stages for the current environment, selectoption 2 on the Environment Options Menu and press Enter. Endevordisplays a Stage Information panel. Use this panel to review the stagedefinitions and optionally, to request a display of the stage definitions foranother environment.

� � ----------------------------- STAGE INFORMATION -------------------------------

COMMAND ===>

CURRENT ENV ===> SMPLTEST

NEXT ENV: SMPLPROD STAGE ID: P

STAGE 1 INFORMATION: Entry Stage: N

ID: T

Name: TEST

Title: UNIT TEST

MCF data set name: CA.ENDEVOR.SMPLTEST.MCF

STAGE 2 INFORMATION: Entry Stage: Y

ID: Q

Name: QA

Title: QUALITY ASSURANCE

MCF data set name: CA.ENDEVOR.SMPLQA.MCF

� �

When you finish viewing the Stage Information display, either fill in the nameof a different environment (and press Enter) to view the stage definitions forthat environment, or press End to return to the Environment Options Menu.

3.3.2 Stage Information Panel FieldsThe following fields appear on the Stage Information panel:

Field Description

Current Env Name of the environment for which the stagedefinitions are shown. Fill in a new name, and pressEnter to display the stage definitions for anotherenvironment.

Next Env Name of the next environment on the map.

Stage ID ID of the first map stage in the next environment.



Field Description

Stage 1 Information�1�

Stage 1 definition information includes:

■ ID — Stage 1 ID■ Name — Stage 1 name■ Title — Stage 1 title■ MCF data set name — Data set name of the

Stage 1 Master Control File (MCF).■ Entry Stage — Indicates whether Stage 1 is the

entry stage.

Stage 2 Information�1�

Stage 2 definition information includes:

■ ID — Stage 2 ID■ Name — Stage 2 name■ Title — Stage 2 title■ MCF data set name — Data set name of the

Stage 2 Master Control File (MCF).■ Entry Stage — Indicates whether Stage 2 is the

entry stage.

Note: �1�: These fields are display-only fields.


3.4 Defining Systems


This section describes how to define a new system.

3.4.1 System Request PanelTo define a new system, select option 3 on the Environment Options Menu,and press Enter. Endevor displays the System Request panel, shown next:

� � ---------------------------- SYSTEM REQUEST ---------------------------------

OPTION ===> k

blank - Display system definition

# - Delete system definition

C - Create system definition

K - Clone system structure

U - Update system definition

ENVIRONMENT ===> SMPLtest

SYSTEM ===> admin

� �

3.4.2 Procedure: New SystemFrom the System Request panel, follow this procedure to define a new systemor access an existing system:

1. Select option C or K to create a new system. For information about optionK, see 3.5, “Cloning System, Subsystem, and Type Definitions” onpage 3-26.

If an option is not entered, Endevor displays a list of the existing systems.You can select a system for editing, press Enter and proceed to step 5.

2. Enter an environment name, if different from the displayed name.

3. Enter a system name or mask.

4. Press Enter.

■ If Endevor displays a System Selection List, select a system, pressEnter, and proceed to Step 5.

■ If Endevor displays a System Definition panel, proceed to Step 5.

5. Type or change information as necessary on the System Definition panel,then press Enter to save the changes. For field descriptions, see SystemDefinition Panel Fields in this chapter.



3.4.3 System Definition PanelThe System Definition panel is shown next:

� �UPDATE -------------------- SYSTEM DEFINITION --------------------------------

COMMAND ===>

CURRENT ENV: SMPLTEST NEXT ENV: SMPLPROD

SYSTEM: ADMIN NEXT SYSTEM ===> ADMIN

SYSTEM TITLE ===> ENDEVOR ADMINISTRATOR APPLICATIONS

UPDATED: 15OCT�2 14:36 BY KTHOMPSON

GENERAL OPTIONS:

COMMENT ===> Y (Y/N) CCID ===> Y (Y/N) REQ ELM JUMP ACK ===> Y (Y/N)

ELEMENT REGISTRATION OPTIONS:

DUPLICATE ELEMENT NAME CHECK ===> N (Y/N) MSG SEVERITY LVL ===> (W/C/E)

DUPLICATE PROC O/P TYPE CHECK ===> N (Y/N) MSG SEVERITY LVL ===> (W/C/E)

SIGN-IN/SIGN-OUT OPTIONS: LAST SYSTEM BACKUP:

ACTIVATE OPTION ===> Y (Y/N) DATE: 22MAR�4

VALIDATE DATA SET ===> N (Y/N) TIME: �6:�3

PROCESSOR TRANSLATION OUTPUT LIBRARIES:

STAGE 1 LOAD LIBRARY ===> CA.ENDEVOR.SMPLEMER.PRCSLOAD

STAGE 1 LIST LIBRARY ===> CA.ENDEVOR.SMPLEMER.PRCSLIST

STAGE 2 LOAD LIBRARY ===> CA.ENDEVOR.SMPLPROD.PRCSLOAD

STAGE 2 LIST LIBRARY ===> CA.ENDEVOR.SMPLPROD.PRCSLIST

� �

Note: A different panel, specific to clone processing, is returned if you requestclone processing. For more information on this panel, see 3.5, “CloningSystem, Subsystem, and Type Definitions” on page 3-26.

3.4.4 Using the System Definition PanelAs shown in the following table, the use of the System Definition panel variesby processing option:

Once you have entered the necessary information on the panel, press Enter toperform the requested processing.

With this option Use this panel to...

Display Display the system definition.

Delete View the system definition and verify that you wantto delete it. Press End if you want to cancel thedelete request.

Create Define a new system.

Update Change an existing system definition.



3.4.5 System Definition Panel FieldsThis section describes the panel fields.

3.4.5.1 Identification Fields

As shown in the following table, the first three fields on the System Definitionpanel identify the environment:

Note: If you are planning to change system names across your map and touse package component validation, see the Packages Guide for informationabout the potential impact of these name changes on package componentvalidation functions.

Field Description

Current Env �1� Name of the current environment.

Next Env �1� Name of the next environment on the map.

System �1� Name of the current system.

Next System Name of this system in the next environment. Youcan enter or change the name in this field when youaccess this panel in create or update mode.

Title Descriptive title for the system (1-50 characters).

Updated �1� This field identifies the date, time, and user ID of thelast user to update the system. When creating a newsystem definition this field is blank.




3.4.5.2 General Options Fields

The following table describes the General Options fields:

Field Description

Comment Indicates whether there must be a comment foractions against this system. Acceptable values are:

■ Y — Each action must have a comment.■ N — Default. Comments are not required for

actions.

CCID Indicates whether there must be CCIDs for actionsagainst this system. Acceptable values are:

■ Y — Each action must have a CCID.■ N — Default. CCIDs are not required for actions.

Req Elm Jump Ack Indicates whether users must specifyACKNOWLEDGE ELM JUMP=Y on the Move panelwhen jumping elements. Acceptable values are:

■ Y — User must specify ACKNOWLEDGE ELMJUMP=Y.

■ N — Default. User does not have to specifyACKNOWLEDGE ELM JUMP=Y.

Note: Jumping occurs when you move an elementfrom one stage to another on a map route, and aversion of the element exists at an intermediate stagethat is not part of the map route.

3.4.5.3 Element Registration Options

These fields contain definitions of the element registration features in effect forthis system. The following table describes the Element Registration Optionsfields:

Field Description

Duplicate ElementName Check

Specifies if Endevor checks to see if the element nameis used in any other subsystems within the system.Default value is N. Valid values are:

■ Y — Endevor checks for the same element namein all the subsystems associated with this system.

■ N — Endevor does not check for the sameelement name in the other subsystems.



Field Description

Msg Severity Lvl Specifies the error message severity level if Endevoris checking for DUPLICATE ELEMENT NAMESwithin the system. Valid values are:

■ C — The same element name exists withinanother subsystem under the same system; theaction is performed and a caution message isissued.

■ W — The same element name exists withinanother subsystem under the same system; theaction is performed and a warning message isissued.

■ E — The same element name exists withinanother subsystem under the same system; theaction is terminated and an error message isissued.

This field must be blank if DUPLICATE ELEMENTNAME CHECK is set to No.

Duplicate Proc O/PType Check

Specifies if Endevor should check for elements thathave the same name and processor output type, andexist within the same or different (non-mapped)systems. The default value is N.

■ Y — Endevor checks if duplicate element nameswith the same processor output type exist withinthe same or different systems.

■ N — Endevor does not check if duplicate elementnames with the same processor output type existwithin the same or different systems.



Field Description

Msg Severity Lvl Processor output registration check message severitylevel.

■ C — The element with the same name andprocessor output type but different type existswithin the same system; or the element with thesame name and processor type exists in adifferent system. The action is performed and acaution message is issued.

■ W — The element with the same name andprocessor output type but different type existswithin the same system; or the element with thesame name and processor type exists in adifferent system. The action is performed and awarning message is issued.

■ E — The element with the same name andprocessor output type but different type existswithin the same system; or the element with thesame name and processor type exists in adifferent system. The action is performed and anerror message is issued.

Must be blank if the Duplicate Proc O/P Type Checkfeature is set to N.

3.4.5.4 Signin/Signout Options Fields

These fields contain definitions of the signin/signout functions in effect for thesystem. The following table describes the Signin/Signout Options fields:

Field Description

Activate Option Acceptable values are:

■ Y — If the signin/signout facility is in use forthis system.

■ N — If the signin/signout facility is not is use.

Note: If signin/signout is set to N, Endevor doesnot allow the signin action, but the signout useridfield is updated. If you set this to Y, an ESMPTBL ispresent, and an element signout is overridden,Endevor searches the table for the user ID that theelement is signed out to. If a match is found, anemail is addressed to the signout user. If no match isfound, no email is sent.

For more information on Email Notification facility,see the appendix “Email Notification.”



Field Description

Validate Data Set Acceptable values are:

■ Y — If the data set validation facility is in use forthis system.

■ N — If the data set validation facility is not inuse.

When an element is retrieved, a "retrieve to" data setname (and member name if the data set is a library)is placed in the element master record.

When an ADD or UPDATE action is performedagainst an element, Endevor compares the "retrieveto" data set name (and member name if applicable) tothe source input data set and member name specifiedfor the action.

■ If the data set (and member) names match, theaction continues.

■ If the names do not match, Endevor checks thevalue in the override signout field. If this valueis:– Y — Processing continues.– N — The action fails.

3.4.5.5 Last System Backup Fields

These fields contain the date and time of the most recent backup of the system.They appear on the System Definition panel in display and delete modes only.These fields are display-only fields. The following table describes the LastSystem Backup fields:

Field Description

Date Date of most recent system backup.

Time Time of most recent system backup.

3.4.5.6 Processor Translation Output Libraries Fields

These fields contain the names of the processor load and list libraries for thesystem. The following table describes the Processor Translation OutputLibraries fields:



Note: To locate an element's processor, Endevor always searches the Stage 1load library first followed by the Stage 2 load library. The search order is thesame, regardless of the element's location.

Field Description

Stage 1 Load Library Name of the Stage 1 processor load library for thissystem. This load library must be different from theload library for Stage 2.

Stage 1 List Library Name of the Stage 1 processor listing library for thissystem. This listing library must be different fromthe load library for Stage 2.

Stage 2 Load Library Name of the Stage 2 processor load library for thissystem. If this load library is the same as the loadlibrary for Stage 1, Endevor issues a warningmessage.

Stage 2 List Library Name of the Stage 2 processor listing library for thissystem. If this listing library is the same as thelisting library for Stage 1, Endevor issues a warningmessage.


3.5 Cloning System, Subsystem, and Type Definitions


Option K (Clone system structures) on the System Request panel can be usedto clone (copy) system, subsystem, and type definitions within or acrossenvironments.

This is a powerful feature when you plan to set up multiple environmentswith the same inventory classifications. In this situation, you only need todefine the systems, subsystems, and types once, then use the System Definition— Clone panel to create the same definitions in the other environments.

Note: Endevor does not validate information in the system, subsystem, andtype definitions that it clones. For example, if a base/image library associatedwith a type definition you want to clone was deleted, Endevor clones the typedefinition with the invalid data set name.

3.5.1 Procedure: Cloning a New SystemFollow this procedure to clone inventory definitions:

1. Access the System Request panel for an environment/system definitionyou want to clone.

2. Type K in the COMMAND field, type the name of a new system in theSYSTEM field, and press Enter.

Result — The System Definition panel appears.

3. Type the following information on the System Definition panel:

■ A title for the new system.■ The environment and system names from which you want to clone the

system definition.■ Y (yes) or N (no) to indicate if you want to clone subsystem and/or

type definitions for this system.

4. Press Enter to clone the requested definitions.

Result — When Endevor has completed cloning, the System Request panelappears.

5. Repeat Steps 1-4 for each inventory definition that you want to clone.



3.5.2 System Definition Panel for CloningThe System Definition panel for cloning is shown next:

� �CLONE -------------------- SYSTEM DEFINITION --------------------------------

COMMAND ===>

TO INFORMATION:

ENVIRONMENT: SMPLTEST

SYSTEM: ADMIN

TITLE ===> Endevor Administrative Applications

FROM INFORMATION:

ENVIRONMENT ===> SMPLprod

SYSTEM ===> admin

GENERAL OPTIONS:

COPY SUBSYSTEMS ===> Y (Y/N)

COPY TYPES ===> Y (Y/N) (TYPES AND PROCESSOR GROUPS)

� �

3.5.3 System Definition Panel FieldsThis section describes the panel fields.

3.5.3.1 To Information

The following table describes the To Information fields. These fields identifythe environment and system for which inventory definitions are cloned.

Field Description

Environment �1� Name of the current environment.

System �1� Name of the new system.

Title Description of the new system.




3.5.3.2 From Information

The following table describes the From Information fields. These fields identifythe environment and system from which inventory definitions are cloned.

Field Description

Environment Name of the source environment. You can changethe environment name to clone a system definitionfrom another environment.

System Name of the system that is cloned.

3.5.3.3 General Options

The following table describes the General Options fields. Use these fields toindicate whether or not to clone subsystem, type, and processor groupdefinitions for the named system.

Field Description

Copy Subsystems Acceptable values are:

■ Y — Default. Clone subsystem definitions.■ N — Do not clone subsystem definitions.

Copy Types Acceptable values are:

■ Y — Default. Clone type and processor groupdefinitions.

■ N — Do not clone type and processor groupdefinitions.


3.6 Defining Subsystems


This section describes how to create, display, update, and delete a subsystem.

3.6.1 Subsystem Request PanelTo display, create, delete, or update subsystems, select option 4 on theEnvironment Options panel, and press Enter. Endevor displays the SubsystemRequest panel, shown next:

� � --------------------------- SUBSYSTEM REQUEST -------------------------------

OPTION ===> c

blank - Display subsystem definition

# - Delete subsystem definition

C - Create subsystem definition

U - Update subsystem definition


SYSTEM ===> ADMIN

SUBSYSTEM ===> Process

� �

3.6.2 Procedure: SubsystemsFrom the System Request panel, follow this procedure to define a subsystem:

1. Select an option (Blank, #, C, U, or K). For information about option K,see 3.5, “Cloning System, Subsystem, and Type Definitions” on page 3-26.



4. Press Enter.

■ If Endevor displays a System Selection List, select a system, pressEnter, and proceed to Step 5.

■ If Endevor displays a Subsystem Definition panel, proceed to Step 5.

5. Type or change information as necessary on the Subsystem Definitionpanel, then press Enter to save the changes.



3.6.3 Subsystem Definition PanelOnce you have entered the necessary information on the Subsystem Definitionpanel, press Enter to perform the requested processing.

� �CREATE ------------------- SUBSYSTEM DEFINITION ------------------------------

COMMAND ===>

CURRENT ENV: SMPLTEST SYSTEM: ADMIN

NEXT ENV: SMPLTEST SYSTEM: ADMIN

SYSTEM TITLE: Endevor Administration Systems

SUBSYSTEM: PROCESS

TITLE ===> Administration of Endevor - Processors, Tools, etc

NEXT SUBSYSTEM ===> PROCESS

UPDATED: BY

� �

3.6.4 Using the Subsystem Definition PanelAs shown in the following table, the use of the Subsystem Definition panelvaries by processing option:

With this option Use this panel to

Display Display the subsystem definition.

Delete View a subsystem definition and verify that you wantto delete it. Press End if you want to cancel a deleterequest.

Create Define a new subsystem.

Update Change an existing subsystem definition.

3.6.5 Subsystem Definition Panel FieldsThe following table describes the fields that appear on the SubsystemDefinition panel:

Field Description

Current Env Name of the current environment.

System Name of the current system.

Next Env Name of the next environment on the map.

System Name of the next system on the map.

System Title Descriptive title for the system.



CAUTION:Type names cannot be changed across the map.

Field Description

Subsystem Name of the subsystem being processed.

Title Descriptive title for the subsystem (1-50 characters).

Next Subsystem Name of this subsystem in the next environment.

Updated Identifies the date, time, and user ID of the last userto update the subsystem. When creating a newsubsystem definition this field is blank.


3.7 Defining Types

3.7 Defining Types

Types identify categories of code. Types are system- and stage-specific. Youmust define types at each stage in an environment. Each system can have 256types defined to it. For example, if you wish to use type COBOL in both thefinance and manufacturing systems, you must define it to both systems in eachstage where the systems are defined.

3.7.1 Type Request PanelTo define a type, select option 5 on the Environment Options panel, and pressEnter. Endevor displays the Type Request panel, shown next:

� �----------------------------- TYPE REQUEST ----------------------------------

OPTION ===>

blank - Display type definition

# - Delete type definition

C - Create type definition

U - Update type definition


SYSTEM ===> ADMIN

TYPE ===> PROCESS

STAGE ===> T T - TEST Q - QA

� �


3.7 Defining Types

3.7.2 Procedure: TypesFrom the Type Request panel, follow this procedure to define a type:

1. In the fields on the Type Request panel, type the following and pressEnter:

■ An option (Blank, #, C, or U).■ An environment name, if different from the displayed name.■ A system name or mask.■ A type name or mask.■ A stage ID.

2. If Endevor displays:

■ A System Selection List, select a system, press Enter, and proceed toStep 3.

■ A Type Selection List, select a type, press Enter, and proceed to Step 4.■ A Type Definition panel, proceed to Step 4.

3. If Endevor displays:

■ A Type Selection List, select a type, press Enter, then proceed to Step4.

■ A Type Definition panel, proceed to Step 4.

4. Type or change information as necessary on the Type Definition panel,then press Enter to save the changes. For field descriptions, see TypeDefinition Panel Fields in this chapter.

For details on how to define binary files, see the appendix “Working withBinary Files.”


3.7 Defining Types

3.7.3 Type Definition PanelThe Type Definition panel is shown next:

� �CREATE ----------------------- TYPE DEFINITION -------------------------------

COMMAND ===>

CURRENT ENV: SMPLTEST STAGE ID: T SYSTEM: ADMIN TYPE: COBOL

NEXT ENV : SMPLTEST STAGE ID: Q SYSTEM: ADMIN TYPE: COBOL

DESCRIPTION ===> Cobol Source Code

UPDATED: BY

----------------- ELEMENT OPTIONS -------------------

FWD/REV/IMG DELTA ===> R (F/R/I) COMPRESS BASE/ENCRYPT NAME ===> Y (Y/N)

DFLT PROC GRP ===> CLENBL REGRESSION PCT ===> 75 REGR SEV ===> W (I/W/C/E)

SOURCE LENGTH ===> 8� COMPARE FROM ===> 7 COMPARE TO ===> 72

AUTO CONSOL ===> Y (Y/N) LANGUAGE ===> cobol PV/LB LANG ===> DATA

CONSOL AT LVL ===> 96 HFS RECFM ===> NL (COMP/CR/CRLF/F/LF/NL/V)

LVLS TO CONSOL ===> 49 DATA FORMAT ===> B FILE EXT ===>

------------- COMPONENT LIST OPTIONS ----------------

FWD/REV DELTA ===> R (F/R) AUTO CONSOL ===> Y (Y/N) CONSOL AT LVL ===> 96

LVLS TO CONSOL ===> 25

--------------------- LIBRARIES ---------------------

BASE/IMAGE LIBRARY ===> CA.ENDEVOR.SMPL&C1ST..BASE

DELTA LIBRARY ===> CA.ENDEVOR.SMPL&C1ST..DELTA

INCLUDE LIBRARY ===>

SOURCE O/P LIBRARY ===>

EXPAND INCLUDES ===> N (Y/N)

� �

3.7.4 Using the Type Definition PanelAs shown in the following table, the use of this panel varies by processingoption:

Once you have entered the necessary information on the panel, press Enter toperform the requested processing.

With this option Use this panel to

Display Display a type definition.

Delete View a type definition and verify that you want todelete it. Press End to cancel a delete request.

Create Define the new type.

Update Modify a type definition.


3.7 Defining Types

3.7.5 Type Definition Panel FieldsThis section describes the panel fields.

3.7.5.1 Identification Fields

The first four fields on the Type Definition panel display the current locationand type name. These fields are display-only fields.

The next four fields indicate the next location on the map, the type name atthat location, and last time the type definition was updated.

CAUTION:Type names cannot be changed across the map.

Field Description


Stage ID Name of the current stage.


Type Name of the type.

Field Description

Next Env Name of the environment at the next map location.

Stage ID Name of the stage at the next map location.

System Name of the system at the next map location.

Type Name of the type at the next map location. You canchange the type name when you access this panel increate or update mode.

Description Displays a 1- to 50-character description of the type.

Updated Identifies the date, time, and user ID of the last userto update the type definition. When creating a newtype definition, this field is blank.


3.7 Defining Types

3.7.5.2 Element Options

The following table describes the Element Options fields:

Field Description

Fwd/Rev/Img Delta Specifies delta storage format for elements of thistype. Acceptable values are:

■ R — Reverse delta format.■ I — Full-image delta format.■ F — Default. Forward delta format.

Compress Base/Encrypt Name

Indicates whether to encrypt and compress the baseform of elements stored in reverse delta format.Acceptable values are:

■ N — Do not compress base and encrypt name.■ Y — Default. Compress base and encrypt name.

Dflt Proc Grp Identifies the processor group for this type. Thedefault is *NOPROC*. When you type or update thename of the processor group, then press Enter,Endevor displays a Processor Group Definition panel.

■ If the specified processor group exists, you canuse the Processor Group Definition panel toverify or modify the processor group.

■ If the specified processor group does not exist,you can use the Processor Group Definition panelto create it as a new processor group. For moreinformation, see the Extended Processors Guide.

Regression Pct Maximum acceptable regression percent for elementsof this type (2 digits). The use of a regressionpercentage of 00 turns off regression testing for thattype — no change or base regression messages areissued.

Note: If the delta storage format for this type is I(full-image delta format), the regression percent mustbe 00.

Regr Sev Determines severity of the error message issued whenEndevor detects regression. Acceptable values are:

■ I — Informational message.■ W — Warning message.■ C — Default. Critical message.■ E — Fatal message.


3.7 Defining Types

Field Description

Source Length Logical record length in source statements. Themaximum allowable value is 32,000. Forvariable-length records, this length does not includethe four-byte record header. For binary files, 32,000is recommended.

Compare From Position within each statement at which Endevorbegins comparing to identify changed statements (5digits in the range 1-32,000). Default is 1.

Compare To Position within each statement at which Endevorstops comparing to identify changed statements (5digits in the range 1-32,000). If you plan to usein-stream data in processors, set this value to 80 fortype Process. Default is 72.

Auto Consol Indicates whether Endevor is to consolidate changelevels automatically. Acceptable values are:

■ Y — Consolidate automatically. When you createthe 96th change level for an element, Endevorconsolidates levels 1-50 into a single level,changing level 96 to level 50.

■ N — Default. Do not consolidate automatically.The LVLS TO CONSOL field must be set to 0.

Language User-specified. Defines the source language for thetype (1-8 characters).

Note: If you specify link-edit in this field, youcannot use name or alias statements in the link stepof processors associated with this type.


3.7 Defining Types

Field Description

PV/LB Lang Required field used for internal purposes as well aswith AllFusion CA-Librarian or AllFusionCA-Panvalet. The 1- to 8-character AllFusionCA-Panvalet or AllFusion CA-Librarian sourcelanguage for the type.

Acceptable values for AllFusion CA-Panvalet:

ANSCOBOL FORTRAN

ALC JCL

AUTOCODE PL/1

BAL RPG

COBOL USER18�

COBOL-72 USER78�

DATA

Acceptable values for AllFusion CA-Librarian:

ASM JCL

COB PLF

DAT PL/1

FOR RPG

FRG TXT

GIS VSB

GOF

Note: If you plan to use in-stream data inprocessors, for type Process, specify in this field:

■ DATA for AllFusion CA-Panvalet

■ DAT for AllFusion CA-Librarian

Consol at Lvl Specifies the number of physical levels at whichEndevor consolidates change levels. Default is 96.

For example, if the value in this field is 70, Endevorconsolidates levels when change level 71 is reached.


3.7 Defining Types

Field Description

HFS RECFM Identifies the record delimiter used in a HFS file. Arecord delimiter is necessary due to the nature ofHFS files. HFS files contain one large data stream;therefore, a delimiter is used to identify individualrecords within that data stream.

This is also true for elements associated with a typedefined as Data Format=Text when the element istransferred between Endevor and CA CM EnterpriseWorkbench. CA CM Enterprise Workbenchrecognizes and appends the delimiter for theexchanged records.

If a delimiter is not specified, the system defaults toNL.

Acceptable delimiter values are:

■ COMP — Variable length records compressed byEndevor

■ CR — Carriage return. ASCII and EBCDIC value"CR". The hex value is '0D'.

■ CRLF — EBCDIC Carriage return\line feed. Thehex value is '0D25'.

■ F — Fixed Length■ LF — EBCDIC line feed. The hex value is '25'.■ NL — Default. EBCDIC new line character. This

is the delimiter used by the OEDIT andOBROWSE editor.

■ V — Variable. The first two bytes of the recordcontain the RDW (record descriptor word). TheRDW contains the length of the entire record,including the RDW.

Note: For details on exchanging binary files betweenEndevor and CA CM Enterprise Workbench, see theappendix “Working with Binary Files.”


3.7 Defining Types

Field Description

Lvls to Consol Indicates the number of deltas to consolidate whenthe number of levels reaches the figure in theCONSOL AT LVL field. Default is 50. This valuemust be zero if AUTO CONSOL=N, and cannot begreater than the value in the CONSOL AT LVL field.

When moving or transferring with history, Endevorconsolidates a number of levels equal to:

■ The number in this field.■ The number of levels needed to reach the value

in the CONSOL AT LVL field.

Example: If the value in this field is 30, and thevalue in the CONSOL AT LVL field is 70, at level 71Endevor consolidates the oldest 30 deltas into a singleconsolidation level (level 01).

Data Format Indicates the element classification type and is usedfor file conversion when transferring files betweenEndevor and CA CM Enterprise Workbench.Acceptable values are:

■ B—Binary. An element exchanged between CACM Enterprise Workbench and Endevor is notmodified. This applies in both directions.

■ T—Text. Character set conversion is applied to anelement.

■ blank—Blank. CA CM Endevor Workbench is notinstalled or this feature does not apply to thistype. If left blank, this value defaults to binarywhen exchanging files between Endevor and CACM Enterprise Workbench.

For details on defining element types associated withfiles exchanged between Endevor and CA CMEnterprise Workbench, see the CA CM EnterpriseWorkbench User Guide.

File Ext Indicates the 0- to 8-character file extension to beused by the CA CM Enterprise Workbench forelements of this type. The extension can containmixed case characters of a-z, A-Z and 0-9, or allblanks. Trailing blanks are supported; embeddedblanks are not supported.

For details on defining element types associated withfiles exchanged between Endevor and CA CMEnterprise Workbench, see the CA CM EnterpriseWorkbench User Guide


3.7 Defining Types

3.7.5.3 Component List Options

The component list base and delta members are stored in the delta librarydefined in the type definition. The following table describes the ComponentList Options fields:

Field Description

Fwd/Rev Delta Specifies delta storage format for component listinformation. Acceptable values are:

■ R — Reverse delta format.■ F — Default. Forward delta format.

Auto Consol Indicates whether Endevor is to consolidate changelevels automatically. Acceptable values are:

■ Y — Consolidate automatically. This is thedefault for component lists.

■ N — Do not consolidate automatically.

Consol at Lvl See the previous description of this field.

Lvls to Consol See the previous description of this field.

3.7.5.4 Libraries

These library names can be specified using symbolics. Available symbolics aredescribed in 3.7.9, “Using Symbolics to Define Base and Delta Libraries” onpage 3-44. The following table describes the Libraries fields:

Field Description

Base/Image Library(Required)

Name of the base library for the type. Can be PDS,AllFusion CA-Panvalet, AllFusion CA-Librarian, orEndevor LIB.

Delta Library(Required)

Name of the delta library for the type. Can be PDS,AllFusion CA-Panvalet, AllFusion CA-Librarian, orEndevor LIB.

Include Library(Optional)

Name of the PDS, ELIB, AllFusion CA-Panvalet, orAllFusion CA-Librarian INCLUDE library for thetype. If specified, members can be included andexpanded from this library.

Note: If an ELIB is specified as an INCLUDE library,it must be reverse delta and have a name that is notencrypted.

Source Library(Optional)

Data set name of source output library.


3.7 Defining Types

Field Description

Expand Includes(Optional)

Indicates whether Include statements are expandedwhen the element is written to the source outputlibrary. Acceptable values are:

■ Y — Expand Include statements.■ N — Do not expand Include statements.

3.7.6 Type Naming ConventionsConsider using generic type names, such as COBOL. You can then create asmany processor groups as you need to handle the variations within each type.For instance, for type COBOL, you could create processor groups to tellEndevor what type of COBOL must be processed. For more information onprocessor groups, see the Extended Processors Guide.

3.7.7 Suggested Naming StandardsA list of suggested naming standards for types follows. This list is notcomplete and is presented here as a guideline only.

ASEMBLER EASYTREV MARKV SORTCNTL

BASIC FORTRAN NETRON SPECS

CLIST JCL PLI TABLES

COBOL LINKCARD REPORTS TRNSFORM

COPYBOOK MACRO RPG UTILITY

3.7.8 Element Storage FormatsYou can store elements in either reverse delta, forward delta, or full-imagedelta format. These delta formats are described next:

■ In reverse delta format, the element base is the current image of theelement. Endevor re-creates previous levels of the element by applyingdelta levels to this base. Using reverse deltas allows you to store theelement base in standard PDS format (not encrypted, non-compressed).

■ In forward delta format, the element base is the source form of the elementwhen it is first added into Endevor. When Endevor processes elementsstored in this format, it applies all delta levels to the base to create thecurrent image of the element. If you select this format, Endevor encryptsand compresses both the base and deltas.

■ In full-image delta format, sites can specify, by element type, that acompare is not performed. Instead, Endevor makes each element level afull image of the element.


3.7 Defining Types

Note: There is no appreciable performance difference between the deltastorage formats.

3.7.8.1 Reverse Delta Considerations

If you select the reverse delta unencrypted storage format, Endevor does notallow two elements with the same name to be stored in the same base library.Keep this in mind when planning your inventory and library structure.Reverse base/deltas:

■ Allow outside utilities to read base libraries directly. Examples of outsideutilities include Fileaid, PMSS, and compilers.

■ Eliminate the need for CONWRITE in processors.

■ Eliminate writes to source output libraries, which also saves DASD.

■ Require separate base libraries by stage and type. Delta libraries can stillbe shared across stages in an environment.

■ Use two I/Os for writes, one for reads.

■ Allow a regular PDS to be used to store element base, and an Endevor LIBdata set to store deltas.


3.7 Defining Types

3.7.8.2 Forward Delta Considerations

With forward base/delta, the element base and subsequent deltas are stored inencrypted/compressed format, which:

■ Provides DASD savings of 10-40%.

■ Allows one type to share a single base and single delta library acrossstages in an environment.

■ Requires one I/O for writes, two for reads.

3.7.8.3 Full-Image Delta Considerations

Endevor performs source compares when moving or transferring elementsfrom one location to another location. There are certain types of elements,such as USS binary executables and machine-generated source, where thissource compare is impossible or unnecessary. In other cases, the Endevorcompare algorithm can require a significant amount of time to complete.

Note: Source changes between element levels are not available whenfull-image delta is used. Only display or print requests for "BROWSE,""CHANGE SUMMARY," and "MASTER" requests are allowed for full-imageelements. Requests for "CHANGES" and "HISTORY" display are notsupported.

With the full-image implementation, Endevor provides the ability to do thefollowing:

■ Track changes by date

■ Track changes by user

■ Associate comments to the change

■ Associate a CCID to the change

■ Have the capability to retrieve prior versions of the element

3.7.9 Using Symbolics to Define Base and Delta LibrariesEndevor allows you to define base, delta, source output, and INCLUDElibraries using symbolics. This allows the same type definition to point todifferent libraries based on the inventory classification of the element.

Organize libraries by Using thissymbolic

or this alias

Site &C1SITE

Environment &C1ENVMNT &C1EN

Stage &C1STAGE &C1ST


3.7 Defining Types

Use these symbolics when specifying base and delta libraries on type definitionpanels. Endevor then replaces the symbolic with the proper information fromthe action request.

Example: The library specification:

&C1SYSTEM..&C1SUBSYS..&C1STGID..SRCLIB

would build a library called SRCLIB for each subsystem/stage combinationwithin a given system.

Organize libraries by Using thissymbolic

or this alias

Stage 1 &C1STAGE1 &C1ST1

Stage 2 &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


3.8 Defining the Type Processing Sequence


You have the option of enforcing an element type processing sequence withinan environment/system definition or through the definition of a single filewhich enforces an element type processing sequence at the site level. WithGlobal Type Sequencing, all elements across all environments follow the sameprocessing sequence.

To define the relative sequence of processing for the various element types inan environment/system, select option 7 from the Environment Options Menu.A type processing sequence is used when multiple element types are processedwithin a single batch request.

Before using this option, you must first define at least two element types forthe system (For more information, see 3.7, “Defining Types” on page 3-32).Each time you add or delete a type thereafter, use option 7 again to redefinethe relative order of processing for the system. When a new type is added, itdefaults to being processed last.

To define Global Type Sequencing, see the chapter “Global TypeSequencing.”

3.8.1 Type Sequence Request PanelWhen you select option 7 on the Environment Options panel and press Enter,Endevor displays the Type Sequence Request panel, shown next:

� �------------------------ TYPE SEQUENCE REQUEST ------------------------------

OPTION ===>

blank - Display type processing sequence

U - Update type processing sequence


SYSTEM ===> ADMIN

STAGE ===> Q T - TEST Q - QA

� �

3.8.2 Procedure: Type Processing SequenceFrom the Type Sequence Request panel, follow this procedure to define thetype processing sequence:

1. Select an option (Blank or U).



4. Enter a stage ID.



5. Press Enter.

■ If Endevor displays a System Selection List, select a system, pressEnter, and then proceed to Step 6.

■ If Endevor displays a Type Processing Sequence Definition panel,proceed to Step 6.

6. To reorder a type, change its sequence number with:

■ A number smaller than the number of the type you want it to precede.

■ A number greater than the number of the type you want it to follow.

7. Press Enter to save the changes. For field descriptions, see Type ProcessingSequencing Panel Fields in this chapter.

Type Processing Sequence Panel: Use this panel to review the currentprocessing sequence for types defined to this stage and to redefine thesequence, if desired. To reorder a type, change the appropriate RelativeProcessing Sequence field with a number:

■ Smaller than that of the type you want it to precede.

■ Greater than that of the type you want it to follow.

Press Enter.

� �UPDATE --------------- TYPE PROCESSING SEQUENCE ----------- Row 1 to 2 of 2


CURRENT ENV: SMPLTEST STAGE ID: Q SYSTEM: ADMIN

NEXT ENV: SMPLPROD STAGE ID: P SYSTEM: ADMIN

UPDATED: 23OCT�2 17:�9 BY CHARPER

RELATIVE

PROCESSING TYPE DESCRIPTION

SEQUENCE

�1� PROCESS ENDEVOR PROCESSOR DEFINITIONS

�2� COBOL Cobol Source Code


� �



3.8.3 Type Processing Sequence Panel FieldsPanel fields are described next. All fields but Relative Processing Sequence aredisplay-only fields.

Field Description


Stage ID ID of the current stage.



Next Stage ID ID of the first stage at the next map location.

Next System Name of the current system at the next map location.

Updated Identifies the date, time, and user ID of the last userto update the processing sequence definition. Whencreating a new type processing sequence, this field isblank.



Field Description

Relative ProcessingSequence

A 3-digit number that defines the relative processingorder for processors executed in batch, for the typedisplayed to the right. Type over this number asappropriate to change the type processing.

Example

Assume you have these processors set up in thissequence:

■ 010 CLISTS ■ 020 JCL ■ 030 PROC ■ 040 COPYBOOK

You decide that you want to run JCL after PROC.You can reorder the processors by typing over theappropriate sequence numbers; in this example, youneed renumber only JCL and PROC, as follows:

■ 025 JCL ■ 015 PROC

Note: Other sequence numbers do not needadjusting. You can use any value from 1- 9 toindicate a changing sequence; that is, instead ofassigning 025 to JCL, you could use 021 or 029. Thevalue you enter must be unique. If you enter aduplicate number, you receive an error message.

When you press Enter, Endevor redisplays the panelto reflect the new order, with the numbers adjustedto start with 010 and increment by 10. In theprevious example, the panel would reflect thefollowing sequence:

■ 010 CLISTS

■ 020 PROC

■ 030 JCL

■ 040 COPYBOOK

Type Name of the type whose relative processing sequenceis shown to the left.

Description Description of the type.


3.9 Updating Type Data Set Definitions


This section describes how to view and change the name of one or more datasets defined for a system.

3.9.1 Type Data Set Request PanelTo view and optionally change the name of one or more data sets defined foruse within a particular system, select option 8 on the Environment OptionsMenu. Data sets are associated with a system through the definition of theelement types within that system.

When you select option 8, and press Enter, Endevor displays the Type Data SetRequest panel.

� � -------------------------- TYPE DATA SET REQUEST ----------------------------

OPTION ===>

blank - Display type data sets

U - Update type data sets


SYSTEM ===> ADMIN

STAGE ===> Q T - TEST Q - QA

� �

3.9.2 Procedure: Type Data Set DefinitionsFrom the Type Data Set Request panel, follow this procedure to view orchange the name of one or more data sets defined for a system:

1. Select an option (Blank or U).



4. Enter a stage ID.

5. Press Enter.

■ If Endevor displays a System Selection List, select a system, press Enterand proceed to Step 6.

■ If Endevor displays a Type Data Set Definition panel, proceed to Step6.

6. Type or change information as necessary on the Type Data Set Definitionpanel, and press Enter to save the changes. For field descriptions, seeType Data Set Panel Fields in this chapter.



3.9.3 Type Data Set PanelEndevor displays this panel after you select a system. It lists the data setsdefined for the element types within that system, in order as they weredefined. To change a library, type over the data set name, and press Enter.

� � DISPLAY ---------------------- TYPE DATA SETS -------------- Row 1 to 3 of 3


CURRENT ENV: SMPLTEST STAGE ID: Q SYSTEM: ADMIN

NEXT ENV: SMPLTEST STAGE ID: Q SYSTEM: ADMIN

DATA SET NAME --- LAST MODIFIED ---

USER DATE TIME TYPE MSG

CA.ENDEVOR.SMPL&C1ST..BASE JSMYTHE 19SEP�2 11:28 ??

CA.ENDEVOR.SMPL&C1ST..DELTA JSMYTHE 19SEP�2 11:28 ??

CA.ENDEVOR.SMPL&C1ST..SRCLIB CHARPER 22OCT�2 17:17 ??


� �

3.9.4 Type Data Set Panel FieldsThe following table describes the panel fields. All fields but Data Set Nameare display-only fields.

Field Description


(Current) Stage ID ID of the current stage.

(Current) System Name of the current system.


(Next) Stage ID ID of the first stage at the next map location.

(Next) System Name of the current system at the next map location.

Data Set Name Name of a library used by an element type definedwithin this system. For each element type, the listincludes the base library, delta library, Includelibrary, and source output library, as appropriate tothe type definition. The libraries are displayed inorder as they were defined to Endevor. Type overthis field to change one or more library names.

Last Modified by The Last Modified By fields identify the user ID ofthe last user to update the type data set as well as thedate and time the update took place.



Field Description

Type Type of library:

■ PO — Partitioned Data Set■ EL — Endevor LIB■ PV — AllFusion CA-Panvalet■ LB — AllFusion CA-Librarian

If the data set name was created using symbolics,Endevor displays "??" in this field.

Msg The following messages can appear in the Msg field:

■ *NCAT — Indicates that the data set is notcatalogued.

■ *ISYM — An invalid Endevor symbol wasspecified in the data set name.

■ *SERR — A symbol parsing error occurred.

■ *IDSN — A new data set name specified thatcontains invalid characters.

■ *NMNT — The volume on which the data set iscatalogued is not accessible (therefore the data setorganization cannot be derived).

■ *MVOL — The data set is a multi-volume dataset.

■ *CTIO — An I/O error occurred while trying tolocate the data set in the system catalog.

■ *ERR — An unexpected error occurred.

■ *UPDT — The data set update was processed andcompleted.


3.10 Displaying Environment Information


This section describes how to display environment information.

3.10.1 Environment Information PanelTo display the environment definitions defined during installation, selectoption E on the Environment Options Menu, and press Enter. Endevordisplays the Environment Information panel. The values displayed on thispanel are obtained from your current Defaults Table.

� �-------------------------- Environment Information ----------------------------

Command ===>

Current Environment,...... SMPLTEST

Title..................... SAMPLE TEST ENVIRONMENT

Next Environment.......... SMPLPROD

User Security Table.......

Resource Security Table...

Journal................... (NONE)

SMF Activity.............. N

SMF Security.............. N

MVS/DB Bridge............. N

� �

To return to the Environment Options Menu, press End.

3.10.2 Environment Information Panel FieldsThe following list describes the panel fields. All fields except for CURRENTENVIRONMENT are display-only fields.

Field Description

Current Environment Name of the current environment. To display thedetails for another environment, enter theenvironment's name in this field, and press Enter.

Title Descriptive title for the current environment.

Next Environment Name of the next environment on the map.

User Security Table Name of the User Security Table currently in use. �1�

Resource SecurityTable

Name of the Resource Security Table currently in use.�1�

Journal Applicable only to users of Endevor's Point in TimeRecovery facility. Name of the journal file used bythis facility.



Field Description

SMF Activity Indicates whether the SMF facility is active for thisenvironment: Y or N �2�

SMF Security Indicates whether SMF security has been turned onfor this environment: Y or N �2�

MVS/DB Bridge Indicates whether the Endevor to CA-Endevor/DBBridge is used in this particular environment: Y or N�2�

Note:

�1�: Applicable for native security only�2�:Y — Yes; N — No


Chapter 4. Mapping

Part of implementing Endevor is to define the stages in the software life cyclesat your site, then organize these stages into environments. This section of thismanual illustrates this process.

Applications in each life cycle follow a unique route through theenvironment/stage locations that you have defined. You can set up as manyroutes as you need to accommodate different life cycles at your site. Theseroutes make up the map for your site.

Endevor uses these routes to automatically add, display, retrieve, move, andgenerate inventory in a given life cycle.

Consider the following examples:

■ Use environments DEV, QA, and PROD for production applications (Route1), with an environment, QFIX, to handle emergency fixes to theapplications (Route 2). Routes 1 and 2 might look like this:

Chapter 4. Mapping 4-1

■ Use environments TSTDEMO and DEMO for the software used todemonstrate the production applications (Route 3). Route 3 might looklike this:

Note: When defining a map, the exit stage for an environment must alwaysbe Stage 2. The entry point into the next environment can be Stage 1 or Stage2.


4.1 Defining a Map

4.1 Defining a Map

You define a map by:

■ Establishing the routes in the Defaults Table.

■ Using the System, Subsystem, and Processor Group Definition panels toidentify inventory classifications at the successive locations in each route.

4.1.1 Establishing Routes in the Defaults TableTo define a route, add the following statement to one or more C1DEFLTSTYPE=ENVRNMNT sections of the Defaults Table:

NEXTENV=(environment-name, stage-id)

The following table explains the previous statment:

Example: To define Route 1 in the preceding section, add the following tothe C1DEFLTS TYPE=ENVRNMNT section:

Note: If you do not provide a stage ID, the specification defaults to Stage 1 ofthe next environment.

Variable Description.

environment-name The name of the next environment on the route.

stage-id The one-character identifier of the first stage in thatenvironment that is on the route. The stage ID isoptional, and if included, must be defined in theDefaults Table.

NEXTENV=QA For environment DEV.

NEXTENV=(PROD,P) For environment QA.

4.1.2 Mapping Inventory ClassificationsYou relate system, subsystem, and processor group names between stages in aroute using the NEXT SYSTEM, NEXT SUBSYSTEM, and NEXT GROUP fieldson the respective definition panels. You can change the following:

■ System and subsystem names when crossing environments.

■ Processor group names when crossing stages, environments, or both.

To simplify your routes, try to keep system, subsystem, type, and processorgroup names consistent across stages and environments.


4.1 Defining a Map

Note: If you plan to change system or subsystem names across your map anduse package component validation, see the Packages Guide for informationabout the potential impact of these name changes on package componentvalidation functions.

To continue the Route 1 example, assume that there are the followinginventory classifications:

■ System FINANCE in all environments.

■ Subsystem PO in all Finance systems.

■ Type COBOL in all stages on the route within the Finance system.

■ Processor group BTCHCOB in all stages on the route within type COBOL.

The following table indicates the values the administrator would enter in theNEXT SYSTEM, NEXT SUBSYSTEM, and NEXT GROUP fields:

For procedures and descriptions of these panels, see Chapter 3, “DefiningInventory Structures” (system and subsystem definitions) and the ExtendedProcessors Guide (processor group definition).

DEVUNIT

DEVINT

QAQA

QAHOLD

PRODFIX

PRODPROD

NEXTSYSTEM

FINANCE FINANCE FINANCE FINANCE NONE NONE

NEXTSUBSYSTEM

PO PO PO PO NONE NONE

NEXTGROUP

BTCHCOB BTCHCOB BTCHCOB BTCHCOB N/A NONE

Note: Stage 1, Fix, of environment PROD, is not one of the locations onthis map route, making a next group specification "not applicable".


4.2 Design Strategies and Guidelines


This section describes the strategies and guidelines for defining routes.

4.2.1 RoutesThe routes that you develop for your site can have a significant impact onyour success in using Endevor. When defining routes, keep the followingpoints in mind:

■ System and subsystem names can change only when going from oneenvironment to another.

■ Processor group names can change when going between stages or betweenenvironments.

The examples that follow present two strategies for defining routes. Use theseexamples as a starting point when developing your own maps.

4.2.2 Stand-alone RoutesYou can have more than one route in your map. For example, you mightcreate one route for the production software life cycle, and a second route forthe life cycle of the demonstration system for this production software.

Each route is defined separately as follows:

■ Route 1 includes environments DEV, QA, and PROD.

■ Route 2 includes environments TSTDEMO and DEMO.



4.2.3 Converging RoutesDifferent routes can converge to include the same stages. For example, a sitemay have different environments for developing financial, manufacturing, andadministrative applications, but have only one QA and one productionenvironment. Routes for this site might look like this:

There are four routes at this site:

■ Route 1 includes environments DEVFIN, QA, and PROD.

■ Route 2 includes environments DEVMFG, QA, and PROD.

■ Route 3 includes environments DEVADMIN, QA, and PROD.

■ Route 4 includes environments QFIX and PROD.



4.2.4 Converging Systems within a RouteThis example suggests a way to take advantage of map routes whileminimizing the number of environments defined in the Defaults Table.

Consider an organization where Bill and Mary are developing a purchaseorder application. Quality assurance work on the completed PO applicationtakes place in environment QA, and the production application is maintainedin environment PROD.

To keep a single development environment (DEV), the administrator createssystem BILL and system MARY in environment DEV, then defines subsystemPO to each of these systems. All four developers are working on COBOLprograms, which have processor group COBOL in all stages of the route.

The administrator defines an environment map by adding the following lines:

The administrator fills in the NEXT SYSTEM, NEXT SUBSYTEM, and NEXTGROUP fields on the respective definition panels as follows:

NEXTENV=QA To the C1DEFLTS TYPE=ENVRNMNTsection for environment DEV.

NEXTENV=(PROD,P) To the C1DEFLTS TYPE=ENVRNMNTsection for environment QA.

DEV UNIT DEV INT QA QA QAHOLD

PRODFIX

PRODPROD

NEXTSYSTEM

FINANCE(on system BILLand system MARYdefinition panels)

FINANCE(on system BILLand system MARYdefinition panels)

FINANCE FINANCE NONE NONE

NEXTSUBSYSTEM

PO PO PO PO NONE NONE

NEXTGROUP

BTCHCOB BTCHCOB BTCHCOB BTCHCOB N/A NONE



This route looks like this:

4.2.5 Implementation ChecklistWhen defining routes, follow the following procedure:

1. Set up routes that reflect your software life cycles. Draw a diagram of theroutes first, using the previous examples as models.

2. Establish the routes in the Defaults Table.

3. Use the System, Subsystem, and Processor Group Definition panels toidentify inventory classifications and processor groups at the successivelocations in each route.

Note: You can also define your maps using batch SCL commands. Fordetails, see the SCL Reference Guide.

4. Run CONRPT07, System Definition Profile, to verify the routes are setcorrectly. Also, run CONRPT07 whenever you change a route to verifythat you have made the modifications correctly.

For a sample of the CONRPT07, see the Reports Guide.


Chapter 5. Element Registration

The element registration feature enables you to choose whether you want torestrict the use of the same element name. Duplicate element names can beproblematic; however, there are situations where they are desirable - forexample, the same element name is used for a program as well as its JCL.

When you define a system, Endevor provides two options that enable you toallow or disallow duplicate element names. One option enables you to controlthe use of duplicate element names across subsystems within the system. Theother option enables you to control the use of duplicate element names at theprocessor group level within the system. Both ways of controlling duplicateelement names can be made to apply across systems.

Note: Verify you are using the same message severity level for the system ineach environment where the system appears. If you do not, element actionsmay behave in an unpredictable manner. Similarly, if element registration isactivated for a system, make sure it is activated in each environment in whichit appears.

Chapter 5. Element Registration 5-1

5.1 Controlling Duplicate Element Names at the System and Subsystem Level

5.1 Controlling Duplicate Element Names at the Systemand Subsystem Level

The Element Registration option enables you to control whether duplicateelement names are allowed across subsystems within a system. During actionprocessing, when the subsystem associated with the element is validated,Endevor checks the option to see if duplicate element names are allowed.

By default, element name registration is defined at the system level on thesystem definition. You can also specify the element name registration optionsyou want to apply to element name registration across systems. This is anoptional feature you can activiate in the optional features table ENCOPTBL byturning on the option REGISTER_ACROSS_SYSTEMS. If this option is turnedon, Endevor ignores the element name registration setting on the systemdefinitions.

System Definition Parameters

The System Definition parameters Duplicate Element Name Check and MsgSeverity Lvl, govern this option. You can specify the following parametervalues:

Value Description

E (Error) The same element name exists within another subsystemunder the same system; the action is terminated and an errormessage is issued.

C (Caution) The same element name exists within another subsystemunder the same system; the action is performed and a cautionmessage is issued.

W(Warning)

The same element name exists within another subsystemunder the same system; the action is performed and a warningmessage is issued.



The System Definition panel displays the parameter values in the DuplicateElement Name Check and Msg Severity Lvl fields highlighted in the followingscreen:


COMMAND ===>


SYSTEM: FINANCE NEXT SYSTEM ===> FINANCE

SYSTEM TITLE ===> FINANCIAL APPLICATIONS


GENERAL OPTIONS:



DUPLICATE ELEMENT NAME CHECK ===> N (Y/N) MSG SEVERITY LVL ===> (W/C/E)DUPLICATE PROC O/P TYPE CHECK ===> N (Y/N) MSG SEVERITY LVL ===> (W/C/E)

SIGN-IN/SIGN-OUT OPTIONS:

ACTIVATE OPTION ===> Y (Y/N)

VALIDATE DATA SET ===> N (Y/N)






� �

Element Registration Across Systems

If you turn on the optional feature REGISTER_ACROSS_SYSTEMS inENCOPTBL, then Endevor issues a message if an element is added or createdand another element with the same name exists in another unmappedsystem/subsystem. If the option is set to E as follows:REGISTER_ACROSS_SYSTEMS=(ON,E), then you cannot create an elementwith the same name unless it is in the map of an existing element. A settingof C or W allows you to create a duplicate element, but a warning or cautionmessage is issued.

Regardless of whether the option is set to E, C, or W, element nameregistration restricts the use of the same element name no matter its type. Withthis option turned off, elements with the same name can only exist in the samesystem/subsystem or in another system (no matter the subsystem). With thisoption turned on, elements with the same element-name (no matter the type)can only exist if one maps to the other.



When this option is turned on, Endevor ignores all option settings for elementname registration at the system definitions. The option-severity set inENCOPTBL will rule over all systems in all the environments no matter whatthe element name registration option settings in the system definitions contain.If the REGISTER_ACROSS_SYSTEMS option is set to OFF, or is not activatedin ENCOPTBL, then the settings on the system definition are used todetermine what rules apply. This option has no impact on the way elementregistration works at the processor group level. You can continue to defineelements with the same name in the same system/subsystem if the DuplicateProc O/P Type check settings allow this.


5.2 Controlling Duplicate Element Names at the Processor Group Level

5.2 Controlling Duplicate Element Names at the ProcessorGroup Level

The processor group-level option enables you to control whether two elementswith the same name, but with a different element type, can exist in the samesystem when both elements are associated to processors groups with the sameprocessor output type. Endevor will use this same criteria to check forelements in different systems if the optional featureELM_REG_CHK_OUTPTYPE_ACROSS_SYSTEMS=ON is turned on in theoptional features table (ENCOPTBL). That is, this optional feature allows youto control if two elements with the same name and processors output type, butwith a different element type, can exist in different systems.

During action processing, if the element already exists at the target locationwithin the same system under a different type with the same output type, theaction is terminated or a warning message issued. This also occurs if anelement with the same name and processor output type, but different type,already exists in a different system, provided the optional feature to checkacross systems is enabled in ENCOPTBL.

As described later in this section, you have the ability to define the type ofoutput produced by a processor group.

To activate the processor group-level option, you must set the appropriateSystem Definition parameter value and define the output type for theprocessor group. Both tasks are described next.

The System Definition fields Duplicate Proc O/P Type Check and MsgSeverity Lvl, activate this option. You can specify the following messageseverity levels, if the check finds that the element with the same name andprocessor output type, but different element type, exists in the same system, orin a different system:

Value Description

W (Warning) The action is performed and a warning message is issued.

C (Caution) The action is performed and a caution message is issued.

E (Error) The action is not performed and an error message is issued



The System Definition panel displays the parameter values in the DuplicateProc O/P Type Check and the Msg Severity Lvl fields highlighted in thefollowing screen:


COMMAND ===>





GENERAL OPTIONS:













� �



Defining the Output Type: After enabling the processor group option, youneed to define the output type. The default output type is a concatenation ofthe element type and processor group names. Using the default value ensuresthere are no registration conflicts. Alternatively, you can define the outputtype using the Processor Group Definition panel. The output type field,PROCESSOR O/P TYPE, is 16-characters long. In the following example, weuse LOADMODULE as the output type for the generate processor. The outputtype is copied to the element catalog record segment when the element isadded or updated.

� �CREATE ----------------- PROCESSOR GROUP DEFINITION --------------------------

COMMAND ===>

CURRENT ENV: SMPLTEST STAGE ID: Q SYSTEM: ADMIN TYPE: COBOL

NEXT ENV: SMPLPROD STAGE ID: P SYSTEM: ADMIN TYPE: COBOL

PROCESSOR GROUP: CLENBL PROCESSOR O/P TYPE ===> LOADMODULE

DESCRIPTION ===> COBOL/LE COMPILE AND LINK, LISTING IS STORED

NEXT PRCS GROUP ===> CLENBL

UPDATED: BY

----------------------- OUTPUT MANAGEMENT INFORMATION -----------------------

PROCESSOR TO USE FOR MOVE ACTION ===> M (M/G)

PROCESSOR TO USE FOR TRANSFER ACTION ===> G (M/G)

S - Browse Symbolics L - List Processor

U - Update Symbolics

FOREGROUND EXECUTION

GENERATE PROCESSOR ===> GCIINBL ===> Y (Y/N)

DELETE PROCESSOR ===> DLODNNL ===> Y (Y/N)

MOVE PROCESSOR ===> MLODNNL ===> Y (Y/N)

� �

You can implement the processor group option for selected inventory. For theinventory that should not be checked, leave the output value as it is originallyset; that is, a concatenation of the element type and processor group names.Using the default value ensures there are no registration conflicts.

For more information regarding processor groups, see the Extended ProcessorsGuide.


Chapter 6. Optional Features

This chapter describes how to install some of the optional features providedwith the Endevor.

If you are new to using Endevor you should become familiar with Endevorbasics before activating the optional features.

Chapter 6. Optional Features 6-1

6.1 Endevor Optional Feature Table ENCOPTBL

6.1 Endevor Optional Feature Table ENCOPTBL

The optional feature table (OFT) supplied with Endevor provides you with asimple, easy-to-use mechanism to customize the product for use at your site.This facility enables you to configure your implementation of Endevor byspecifying which features you want to activate. After modifying the OFTsource, you must assemble and link the table, placing the output into theEndevor execution library.

The optional feature table embedded in ENCOPTNS provides a description ofeach option along with detailed information on parameter values anddownstream effects.

The OFT source, as distributed, contains each option already coded, butinactive. To activate an entry, remove the asterisk (*) in column 1 and verifythat the second parameter, if required, contains the appropriate value.Assemble and link-edit the table using member BC1JOPTF, located inEndevor's JCLLIB.

The optional feature table is provided with the Endevor installation files asmember ENCOPTBL in the installation SOURCE library (iprfx.iqual.SOURCE).


6.2 The Features Discussed in This Chapter


Endevor provides you with several optional features. After you have installedand verified the base Endevor system, your site can incorporate other relevantcomponents of Endevor.

The features discussed in this manual include the following:

Feature Description

CCID definition data set This option allows you topredefine the CCIDs to be usedat your site.

SMF interface This option allows you torecord each action and eachsecurity violation that occursduring Endevor processing.

Interface for AllFusionCA-Panvalet

This option allows you to useAllFusion CA-Panvalet as thesource library manager. Theoption is also necessary if youwant to expand imbedded++INCLUDE statements.

++CONTROL password This option is used when youwant Endevor to supply the++CONTROL password foreach AllFusion CA-Panvaletlibrary that Endevor accesses.

Interface for CA-AllFusionCA-Librarian

This option allows you to useCA-AllFusion CA-Librarian asthe source library manager.The option is necessary if youwant to expand imbedded INCstatements.

Alternate ID support This option allows you toprotect Endevor-controlleddata sets from direct update byindividual users.



Tip: Enabling some of these features may require that you redefine theEndevor Defaults Table. To expedite the installation process, read through allsections before making any changes. Then, when you are finished, you canmake all necessary changes at one time.

Feature Description

Site-defined Symbolics This option allows you toreference user-defined,site-wide symbolics fromwithin data set namespecifications for base, delta,source output, and includelibraries, as well as fromprocessors.

Parmlib data set This option identifies theParmlib data set used at yoursite. This library contains yoursite's Type Sequence member ifone is defined at your site.

Type Sequence member Name of the member withinthe Parmlib data set thatdefines your site typeprocessing sequence.


6.3 The Features Not Discussed in this Chapter


Endevor offers several other optional features, which are discussed in detail inother chapters in this guide and in other guides. The following table liststhese optional features and where you can find information about them:

Optional Feature More Information

User customizable dialogdefaults

Dialog Options Fields in the chapter“The ISPF Dialog OptionsConfiguration Table”

Site Defaults Table selection exit(ENUXSITE)

Using an Alternate Defaults Table inthe chapter “The Alternate DefaultsTable”

Package processing Packages Guide

Security (all types)a Security Guide

User exitsb Exits Guide

Reports Reports Guide

Notification Facility Administrator Guide appendix “EmailNotification,” Exits Guide, andUtilities Guide

API (Application ProgramInterface)

API Guide

CSV(Comma Separated ValueUtility)

Utilities Guide

PDM (Parallel DevelopmentOption)

Parallel Development Option Guide

ROSCOE Interface for CA-Roscoe Guide

PITR (Point-in-Time Recovery) Utilities Guide

Information/ManagementInterface

Interface for IBM Tivoli InformationManagement Administration Guide



a If you are using the security feature, be sure the security tables are copiedinto the appropriate authorized library.

b If you are using user exits, be sure they are copied into the appropriateauthorized library.

Optional Feature More Information

DB2 Endevor for DB2 Installation Guideand Endevor for DB2 User Guide

Endevor/DB-MVS Bridge Endevor to CA-Endevor/DB BridgeAdministrator Guide


6.4 The CCID Definition Data Set


If you want to use CCID validation, you must build a CCID definition dataset. Before you can build the data set, though, you need to specify a CCIDvalidation data set name in the Defaults Table, using the CIPODSN parameter.For definition of the CIPODSN parameter, see the chapter “The DefaultsTable.”

6.4.1 Install the CCID Definition Data SetThe following are the three steps involved in installing the CCID definitiondata set:

Step Action

1 Allocate the data set.

2 Initialize the data set.

3 Add the data set name to theEndevor Defaults Table.

6.4.2 Step 1: Allocate the Data SetAllocate the CCID validation data set using the standard ISPF data setutilities--option 3.2 from the ISPF/PDF Primary Option Menu. The data setmust have the following attributes:

The data set name you use must be the same as that specified for theCIPODSN parameter in the Defaults Table. The data set name can be any validname that conforms to your site's naming conventions.

Parameter Value

LRECL= 80

RECFM= FB

DSORG= PS

BLKSIZE= Any multiple of 80



6.4.3 Step 2: Initialize the Data SetYou can initialize the CCID validation data set by copying a template suppliedby CA. Because Endevor requires information to be placed in certain columns,it is recommended that you copy member SAMPCIPO into the data setallocated in Step 1. By using this member as a template, you can ensure thatthe fields in the data set are positioned in the correct columns.

Use the standard ISPF copy utility--option 3.3 on the ISPF/PDF PrimaryOption Menu--to copy SAMPCIPO from the sample JCL library(iprfx.iqual.JCLLIB, created during Step 2 of the base installation process) intothe data set.

Use the ISPF edit service to tailor the data set to meet the requirements of yoursite. For description of the contents of the data set, see the Administrator Guide.

6.4.4 Step 3: Add the Data Set Name to the Defaults TableAfter you have allocated and initialized the CCID validation data set, you needto add the data set name to the Endevor Defaults Table. To do this, add thevalid data set name to the CIPODSN parameter, as follows:Col Col Col

1 16 72

↓ ↓ ↓

C1DEFLTS TYPE=MAIN, X

.

.

.

CIPODSN=, CCID VALIDATION DATASET NAME X

.

.

.

For additional information about editing the table, see the discussion of theDefaults Table in the chapter “The Defaults Table.”

Do not update the CIPODSN parameter in the Defaults Table before allocatingthe CCID validation data set. If CIPODSN contains a non-null entry, Endevorassumes that the entry is a data set name and looks for that data set duringinitialization. If Endevor cannot find the data set, it generates an errormessage. Therefore, before using Endevor, be sure that the CCID validationdata set is allocated and defined appropriately.


6.5 The SMF Interface


The SMF interface records each action and each security violation that occursduring Endevor processing. SMF recording is done on anenvironment-by-environment basis. Therefore, you can selectively enable SMFrecording for each of your environments.

For information about SMF recording, see the Administrator Guide.

6.5.1 Set the SMF Parameters in the Defaults TableTo request this interface, you must modify the Endevor Defaults Table toinclude the appropriate SMF parameters. Do this by specifying the followingparameters:

■ SMFREC#= in the TYPE=MAIN macro

■ SMFACT= and SMFSEC= in the TYPE=ENVRNMNT macro

For additional information about editing the table, see the chapter “TheDefaults Table.”

6.5.2 TYPE=MAIN ParametersSpecify the SMFREC# parameter in the TYPE=MAIN portion of the DefaultsTable:Col Col Col

1 16 72

↓ ↓ ↓


.

.

.

SMFREC#=�, SMF RECORD NUMBER X

.

.

.

This is the SMF record number assigned to SMF records written by Endevor atthis site. For more information about this SMF parameter, see the Type=Mainparameter definitions in the chapter “The Defaults Table.”

Tip: Talk to a systems programmer at your site to ensure that you are indeedcollecting the SMF records related to the record number specified in theSMFREC# parameter. Recording records is controlled inSYS1.PARMLIB(SMFPRMxx).



6.5.3 TYPE=ENVRNMNT ParametersYou should specify at least one of the following SMF parameters in theTYPE=ENVRNMNT portion of the Defaults Table:Col Col Col

1 16 72

↓ ↓ ↓

C1DEFLTS TYPE=ENVRNMNT, X

.

.

.

SMFACT=N, SMF ACTIVITY OPTION (Y/N) X

SMFSEC=N, SMF SECURITY OPTION (Y/N) X

.

.

.

These parameters are defined as follows:

For more information about these SMF parameters, see theTYPE=ENVRNMNT parameter definitions in the chapter “The Defaults Table.”

Parameter Definition

SMFACT Indicates whether Endevorshould write out SMF ActionRecords. Set this parameter to Yif you want the Action Recordswritten out. Otherwise, set theparameter to N.

SMFSEC Indicates whether Endevorshould write out SMF SecurityRecords. Set this parameter toY if you want the SecurityRecords written out. Otherwise,set the parameter to N.


6.6 The Endevor AllFusion CA-Panvalet Interface


If your site is (or will be) using AllFusion CA-Panvalet as a source librarymanager, you must link-edit the AllFusion CA-Panvalet access method (PAM)module into several of the Endevor AllFusion CA-Panvalet Interface modules.Installing this interface also allows you to expand ++INCLUDE statements.These statements are expanded from either a AllFusion CA-Panvalet library ora PDS when the interface is enabled.

Note: Be sure that the AllFusion CA-Panvalet installation does not suppresslevel checking on the AllFusion CA-Panvalet UPDATE ALL command.

6.6.1 Link-Edit the Access ModuleThe following are the three steps involved in link-editing the AllFusionCA-PAnvalet access modules to Endevor AllFusion CA-Panvalet Interfacemodules:

Step Action

1 Edit member BC1JPAN (in the JCLlibrary) to include the name ofyour AllFusion CA-Panvalet loadlibrary.

2 Link-edit the PAM module, usingBC1JPAN. Place the output loadmodule that was created by thisjob into CONLIB.

3 Redefine the Defaults Table, ifnecessary, to specify PV in theLIBENV parameter.



6.6.2 Step 1: Edit BC1JPANTailor the BC1JPAN JCL to provide the correct name of your AllFusionCA-Panvalet load library on the PAMLIB DD statement. BC1JPAN JCL, whichis supplied on the installation tape, is shown next://� ( COPY JOBCARD )

//��

//� �

//� BC1JPAN - THIS JOB WILL LINKEDIT THE NECESSARY PANVALET �

//� SOFTWARE TO PROVIDE THE ENDEVOR �

//� PANVALET INTERFACE SUPPORT �

//� PAMLIB - IS THE CURRENT SYSTEM PANVALET LIBRARY AND SHOULD �

//� BE MODIFIED FOR YOUR SITES NAMING �

//� �

//��

//PANLINK EXEC PGM=IEWL,PARM='LIST,NCAL,REUSE,XREF,SIZE=(256K,64K)'

//SYSLMOD DD DISP=SHR,DSN=iprfx.iqual.CONLIB

//PAMLIB DD DSN=SYS2.PANVALET.LOAD,DISP=SHR

//SYSUT1 DD UNIT=tdisk,SPACE=(CYL,(5,3))

//SYSPRINT DD SYSOUT=�

//SYSLIN DD �

.

LINK-EDIT CONTROL STATEMENTS START HERE

.

.

.

6.6.3 Step 2: Run BC1JPANIf you have not already done so, copy your JOBCARD member to thebeginning of BC1JPAN. Then submit the job for execution. BC1JPAN link-editsthe PAM module and places the output load module in CONLIB.

6.6.4 Step 3: Set the AllFusion CA-Panvalet Parameters in theDefaults Table

Redefine the Endevor Defaults Table, if necessary, to specify the value PV inthe LIBENV parameter (in the TYPE=MAIN macro). Update the LIBENVPparameter to specify that AllFusion CA-Panvalet is installed at your site, asshown next:Col Col Col

1 16 72

↓ ↓ ↓


.

.

.

LIBENV=PV, X

LIBENVP=Y, X

.

.

.



6.7 The ++CONTROL Password Interface


Endevor provides a ++CONTROL password feature, which is available to theEndevor for AllFusion CA-Panvalet Interface. This feature is optional, andallows Endevor to supply the ++CONTROL password for each AllFusionCA-Panvalet library that will be accessed by Endevor. The password interfaceis intended for AllFusion CA-Panvalet libraries that are currentlypassword-protected.

6.7.1 Install the ++CONTROL Password InterfaceThe following table describes the three steps involved in installing the++CONTROL password interface:

Step Action

1 Edit member BC1JCNTL.

2 Run BC1JCNTL.

3 Copy the output into the Endevorauthorized library.

6.7.2 Step 1: Edit BC1JCNTLTo install the ++CONTROL password interface, you need to provide theAllFusion CA-Panvalet library data set name and password for each librarythat is password-protected. Use member BC1JCNTL, which is supplied in theinstallation JCL library, to do this. The JCL contains the instructions you needto define each library and password.



The BC1JCNTL JCL is shown next. The fields you need to edit are highlighted.

//�(JOBCARD)

//��

//� BC1JCNTL - COMPILE PANVALET ++CONTROL PASSWORD TABLE C1PTCNTL.

//�

//� TO DO THIS MAKE THE FOLLOWING CHANGES:

//�

//� 1. FOR EACH LIBRARY THAT IS PASSWORD PROTECTED,

//� CODE IN THE PANVALET LIBRARY DATASET NAME,

//� (PANPRFX.PANQUAL.PANLIBN) AND PASSWORD (CTLCODE)

//� BELOW.

//� - IF MORE ENTRIES ARE NEEDED DUPLICATE THE

//� 3 LINES FOR EACH ENTRY AND INCREMENT

//� THE PANLIBN LABEL FOR EACH.

//� - IF FEWER THAN THE 4 ENTRIES SUPPLIED ARE NEEDED

//� DELETE THE UNNEEDED ENTRIES.

//� 2. LINK MODULE INTO YOUR AUTHORIZED LOAD LIBRARY.

//�

//� NOTE: MODULE MUST BE NAMED C1PTCNTL.

//�

//��

//STEP1 EXEC PGM=ASMA9�,PARM='NODECK,OBJECT,NOTERM'

//SYSLIB DD DISP=SHR,DSN=SYS1.MACLIB

//SYSLIN DD DISP=(,PASS,DELETE),DSN=&&SYSLIN,

// UNIT=tdisk,SPACE=(TRK,(3,5),RLSE),

// DCB=(RECFM=FB,LRECL=8�,BLKSIZE=312�)




//SYSPUNCH DD DUMMY


//SYSIN DD �

C1PTCNTL TITLE 'C1PTCNTL ++CONTROL CODE TABLE'

CSECT

�

� THIS IS A HEADER WHICH IS THE SAME SIZE OF AN ENTRY

� WITHOUT THIS, THE FIRST ENTRY WILL BE SKIPPED.

�

DC X'�7FE'

DC CL8'C1PTCNTL'

DC CL54' '

�

� TAGS ARE NOT NEEDED BUT WILL KEEP THE SEPARATION EASIER

�

PANLIBA DC CL44'panprfx.PANQUAL.PANLIBA' <=== PANLIB DSNCTLCODA DC CL8'�' <=== PASSWORD (8 CHAR MAX) DC CL12' '

�

PANLIBB DC CL44'panprfx.PANQUAL.PANLIBB' <=== PANLIB DSNCTLCODB DC CL8'�' <=== PASSWORD (8 CHAR MAX) DC CL12' '

�



PANLIBC DC CL44'panprfx.PANQUAL.PANLIBC' <=== PANLIB DSNCTLCODC DC CL8'�' <=== PASSWORD (8 CHAR MAX) DC CL12' '

�

PANLIBD DC CL44'panprfx.PANQUAL.PANLIBD' <=== PANLIB DSNCTLCODD DC CL8'�' <=== PASSWORD (8 CHAR MAX) DC CL12' '

�

� THIS LAST ENTRY IS REQUIRED OR AN SOC4 ABEND WILL OCCUR

�

LSTENTRY DC XL4'FFFFFFFF'

�

END

/� LINK THE TABLE INTO YOUR AUTHORIZED LOAD LIBRARY

//STEP2 EXEC PGM=IEWL,COND=(�,NE),

// PARM='LIST,NCAL,RENT,XREF,SIZE=(256K,64K)',

//SYSLIN DD DSN=&&SYSLIN,DISP=(OLD,DELETE)

//SYSLMOD DD DISP=SHR,DSN=uprfx.UQUAL.AUTHLIB(C1PTCNTL)



6.7.3 Step 2: Run BC1JCNTLIf you have not already done so, copy the JOBCARD member (in the JCLlibrary) to the beginning of BC1JCNTL. Then submit the job for execution.Module C1PTCNTL is created and placed in your uprfx.uqual.AUTHLIB.


6.8 The Endevor AllFusion CA-Librarian Interface


If your site is using AllFusion CA-Librarian as its source library manager, youneed to install the AllFusion CA-Librarian Interface. This interface allows youto access members stored within the AllFusion CA-Librarian data sets.

Endevor can add, update, or read from a AllFusion CA-Librarian data set.Whenever Endevor adds or updates, it always adds or replaces the entiremember, ignoring--but preserving--AllFusion CA-Librarian sequence numbers.

6.8.1 External and Internal LibrariesThe AllFusion CA-Librarian data sets can be used as external libraries; forexample, as development libraries, INCLUDE libraries, or target libraries.

It is not recommended that you use AllFusion CA-Librarian data sets asinternal (base and delta) libraries, for performance and external usabilityissues. If you do use these data sets as Endevor base and delta libraries, notethat members written into the libraries are always stored with sequencenumbers in columns 81-86, regardless of the type of language used. This isdone to protect Endevor information.

6.8.2 Set the AllFusion CA-Librarian Parameters in the Defaults TableRedefine the Endevor Defaults Table as follows, if necessary, to accommodatefor the AllFusion CA-Librarian Interface:

■ Specify the value LB in the LIBENV parameter (in the TYPE=MAINmacro).

■ Update the LIBENVP parameter to specify that AllFusion CA-Librarian isinstalled at your site.

■ Specify the name of the AllFusion CA-Librarian load module for your sitein the LIBRPGM parameter. (In the following example, the load modulename is AFOLIBR, the default name delivered by CA-AllFusionCA-Librarian.)Col Col Col

1 16 72

↓ ↓ ↓


.

.

.

LIBENV=LB, X LIBENVP=Y, X

LIBRPGM=AFOLIBR, X

.

.

.




6.8.3 Should You Customize for AllFusion CA-Librarian?Using AllFusion CA-Librarian may require some customization at your site.Because Endevor automatically specifies columns 81-86 as the sequencecolumns for AllFusion CA-Librarian, and preserves all 80 columns of data (asapplicable), it is not absolutely necessary to customize the interface atinstallation.

■ If you do not require the Sequence Update facility (SEQUPD) ofAllFusion CA-Librarian, you do not need to customize Endevor to run theEndevor AllFusion CA-Librarian Interface.

■ If you need to control the sequence column numbers by type (if you areusing the Sequence Update facility), you must customize your installation.Customization allows you to keep the AllFusion CA-Librarian members inexternal AllFusion CA-Librarian data sets, which may be updated by usingimbedded sequence numbers.

For example, some sites have families of programs that are all updated by acommon set of changes to a central copy of a particular type of program, suchas a payroll program with several variants. The same set of changes can beapplied to all programs by using the AllFusion CA-Librarian SEQUPD facility.In this example, customization would be required, as the client would need toretain control of the sequence number columns.

6.8.4 Considerations When CustomizingIf you decide to customize the Endevor AllFusion CA-Librarian Interface foryour site, you must consider the following:

■ Endevor must know the sequence columns for the element type beingprocessed.

■ Endevor must preserve the original set of sequence numbers within theelement, so subsequent sequence number updates will match correctly.

■ Endevor must always set the sequence columns when writing the elementto an external AllFusion CA-Librarian data set, so AllFusion CA-Librarianwill allow you to use these sequence columns for SEQUPD processing.This procedure informs AllFusion CA-Librarian that these specific columnsare available, which in turn prevents automatic renumbering by AllFusionCA-Librarian.

■ You must ensure that any element types customized for sequence numberprocessing have valid, ascending numeric sequence numbers within theelement.



6.8.5 Customize Your Site for the AllFusion CA-LibrarianThere are two steps involved in customizing your installation for the EndevorAllFusion CA-Librarian Interface. These steps are described next:

Step Action

1 Assemble and link-edit a languagedefinition table to define the sequencecolumns by internal language foryour installation.

2 Define distinct Endevor types forthose elements that will use SEQUPDprocessing.

6.8.6 Step 1: Define Sequence Number ColumnsUse member BC1JLIBR, which is supplied in the installation JCL library, todefine sequence number columns by language.

The BC1JLIBR JCL is shown next:

//�(JOBCARD)

//�-------------------------------------------------------------------�

//� �

//� �

//� NAME: BC1JLIBR �

//� �

//� PURPOSE - ASSEMBLE AND LINK LIBRARIAN SEQUENCE NUMBER TABLE �

//� �

//� STEPS: �

//� ASSEMBLE: ASSEMBLE THE LIBRARIAN SEQUENCE NUMBER TABLE �

//� LINK: LINK EDIT THE LIBRARIAN SEQUENCE NUMBER TABLE INTO THE �

//� ENDEVOR CONLIB LIBRARY. �

//� NOTE: THE TABLE NAME MUST BE C1LIBRSQ. �

//�-------------------------------------------------------------------�

//ASSEMBLE EXEC PGM=ASMA9�,REGION=2�48K,

// PARM='OBJ,NODECK,LIST,XREF(SHORT)'


//SYSLIB DD DISP=SHR,DSN=iprfx.IQUAL.SOURCE

//SYSLIN DD DSN=&&SYSLIN,

// UNIT=tdisk,

// SPACE=(TRK,(5,5)),

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

// DCB=(RECFM=FB,LRECL=8�,BLKSIZE=312�)

//SYSUT1 DD UNIT=tdisk,SPACE=(TRK,(5,5))



//�

//� SAMPLE SEQUENCE NUMBER DEFINITIONS



//�

//SYSIN DD �

C1LIBRSQ LANG=XXX,SEQCOLS=(N1,N2)




C1LIBRSQ END=YES

END

/�

//�------------------------------------------------------------------�

//� LINK EDIT THE TABLE. NOTE: THE OUTPUT LOAD MODULE MUST BE NAMED �

//� C1LIBRSQ �

//�------------------------------------------------------------------�

//LINK EXEC PGM=IEWL,

// REGION=2�48K,

// PARM='RENT,NCAL,XREF,SIZE=(256K,64K)',

// COND=(�,NE)


//SYSLMOD DD DISP=SHR,DSN=iprfx.IQUAL.CONLIB(C1LIBRSQ)

//SYSLIN DD DSN=&&SYSLIN,DISP=(OLD,DELETE)


6.8.7 Edit the BC1JLIBR JCLYou need to edit BC1JLIBR to meet the requirements of your site. Note thehighlighted lines in the JCL. Edit these lines as follows:

■ SYSLMOD DD--Replace iprfx.iqual.conlib with the CONLIB data set nameyou are using.

■ C1LIBRSQ lines--Each C1LIBRSQ line defines the sequence numbercolumns to be used for a particular internal language type. Enter theinformation required by your organization. Each line must specify alanguage (three characters in length, indicated by xxx), as well as twocolumn numbers--a beginning column number (n1) and an ending columnnumber (n2). You must enter one line per language. You can enter asmany lines as necessary.

■ The language types are matched against the PV/LB LANG field on theType Definition panel (see the Administrator Guide).

The following list reflects the language codes Endevor uses (see also thefollowing Note):

Language Code

ASM (Assembler) GOF

COB (COBOL) JCL

DAT (Data) PLF

FOR (FORTRAN) PLI



The following examples illustrate acceptable C1LIBRSQ lines:C1LIBRSQ LANG=COB,SEQCOLS=(1,6)

In this example, the language type is COBOL and the sequence numbercolumns are 1 through 6.C1LIBRSQ LANG=ASM,SEQCOLS=(73,8�)

In this example, the language type is Assembler and the sequence numbercolumns are 73 through 80.

Any languages not specified in the JCL are stored with sequence columns 81through 86.

Note: If your site uses language codes other than those listed above, contactEndevor Customer Support. An optional patch is available that allows you tomodify the language codes in the JCL to accommodate the codes you areusing.

Language Code

FRG (FORTRAN G) RPG

FRH (FORTRAN H) TXT

GIS VSB

6.8.8 Step 2: Define Endevor TypesYou must determine which Endevor types require the AllFusion CA-LibrarianSEQUPD capability when you define element types for a system. These typesrequire specific information to be entered on the Type Definition panel (see theAdministrator Guide), as follows:

■ The PV/LB LANG field must match one of the languages defined in thelanguage definition table.

■ The COMPARE FROM and COMPARE TO fields must include thesequence column fields defined for that language.

■ Specify N for EXPAND INCLUDES, if the source output library is aAllFusion CA-Librarian data set. (Expanding INCLUDES makes thesequence numbers invalid.)

Note: If the language does not match or the sequence columns are notincluded within the compare columns (or both situations occur), Endevorstores the sequence numbers in columns 81 through 86 when writing toexternal AllFusion CA-Librarian data sets.



6.8.9 Points to RememberWhen defining types for the Endevor AllFusion CA-Librarian Interface, keep inmind the following points.

For element types that are customized for the Endevor AllFusion CA-LibrarianInterface:

■ Avoid EXPAND INCLUDES during add or retrieve processing where thetarget is a AllFusion CA-Librarian data set. Expanding INCLUDES makesthe sequence numbers invalid.

■ Ensure that members have valid sequence numbers in the sequencecolumns. If the numbers are invalid, AllFusion CA-Librarian rejectsmembers during Endevor retrieve processing.

■ If an Endevor member has invalid sequence numbers, retrieve thatmember into an IBM partitioned data set, adjust the sequence numbers,and add the member back into Endevor.

■ If using reverse formatted AllFusion CA-Librarian libraries, you should beaware of how -INC is handled. Endevor will convert the '-' to a hex '02'and be added to the library; Endevor does not want expansion to happenin the base library. Any Endevor action will convert the hex '02' back to a'-'.

For element types that are not customized for AllFusion CA-Librarian:

■ Set the Endevor COMPARE columns to exclude AllFusion CA-Librariansequence columns, to avoid sequence number edit rejections by AllFusionCA-Librarian.


6.9 Alternate ID Support


The alternate ID support feature allows a site to protect the Endevor data sets(that is, base, delta, listing, and source output libraries, as well as MasterControl Files, the package data set, and processor output libraries) from directupdate by users.

When using alternate ID support, a separate administrator's ID is defined toEndevor. This separate--or alternate ID--is granted update authority for theEndevor libraries. When Endevor needs to update these libraries, the systemdoes so using the authorization assigned to the alternate ID.

By defining an alternate ID and assigning it specific update authorization, youcan prevent a user from inadvertently updating particular libraries.

6.9.1 Implement Alternate ID SupportThere are two steps involved in implementing the alternate ID support feature,described next:

Step Action

1 Redefine the Endevor Defaults Tableto accommodate for alternate IDsupport.

2 Use your site's security system tobuild profiles to protect the libraries,and grant update authority to thealternate (administrator's) ID for thoselibraries.

6.9.2 Step 1: Set the Alternate ID Parameters in the Defaults TableYou need to redefine the TYPE=MAIN macro in Endevor Defaults Table toinclude (or update) the parameters highlighted next:Col Col Col

1 16 72

↓ ↓ ↓


.

.

.

RACFGRP=security group name, X RACFPWD=password, X

RACFUID=userid, X

.

.

.



Provide information for each parameter as follows:

■ RACFGRP--Indicate the name of the security group with which thealternate ID is associated. This parameter is optional.

■ RACFPWD--Indicate the password for the alternate ID defined. Thisparameter is optional.

■ RACFUID--Indicate the user ID required for alternate ID support.

6.9.3 Step 2: Build a Security Profile for Endevor LibrariesSee your site's security material, or check with your Security Administrator, tobuild the profiles required to protect the Endevor libraries and grant theappropriate authorization to the alternate ID.

For more information on alternate ID support, see the Security Guide.


6.10 Site-Defined Symbolics


Site-defined symbolics are user-defined symbolic values that you referencewithin dataset name specifications for base, delta, source output, includelibraries, and processors (that is, you can use them wherever you can useEndevor symbolics). At execution time, any site-defined symbolics referencedby a processor are stored with the processor symbolics in the component data.If a site-level symbolic is also specified as a processor symbolic, the processorsymbolic (and processor symbolic override) take precedence.

When Endevor is initialized, the site-defined symbolics are placed intomemory. When Endevor is terminated, the site symbolic storage is released.If more than one Endevor task is executing, each task has its own discrete sitesymbolic storage.

To implement the use of site-defined symbolics, you must define the symbolicand its data value in a table that is assembled and linked into an authorizedload library. Once this is done, you need to update the SYMBOLTBLparameter in the C1DEFLTS table with the name of the site-defined symbolicstable. These actions are described next.

6.10.1 Defining Site SymbolicsUse the following format to define a symbolic and its data value in thesite-defined symbolics table:

$ESYMBOL SYMNAME=#symbolname,SYMDATA=symbolvalue

The following table describes the preceding format:

Item Description

symbolname The symbol name must begin with the # character and is 1 to11 characters in length. The # indicates that the symbol isdefined in the site-defined symbolics table.

symbolvalue The data value associated with the site symbolic is 1 to 70characters in length, with no restrictions on the content ofthe data. If you do not specify a data value for a symbolic,Endevor treats it as a null variable.

Use the JCL member contained in the element BC1JSYMT to create thesite-defined symbolics table.



6.10.2 Updating C1DEFLTSAfter creating the symbolics table, update C1DEFLTS to reflect the table name.Use the SYMBOLTBL= parameter to define the table name, as shown next:

SPFEDIT=SPFEDIT, X

SYMBOLTBL=ESYMBOLS, X

SYSIEWL=SYSIEWLP, X

MIXEDFMT=(DESCRIPTION,COMMENT), X

UIDLOC=(1,7), X

VIOUNIT=VIO, X

WRKUNIT=SYSDA, X

RACFUID=NDVUSER, X

RACFGRP=NDVALT�, X

PKGCSEC=N, X

PKGCVAL=O, X

PKGSEC=ESI, X

PRBLKSZ=��, X

PRLNKSZ=(896K,96K), X

PRLSTSZ=1�, X

MODHLI=BST


ENVNAME=D4�, X

ENVTITL='Development Rel r7',

', X

The Site Information from C1DEFLTS panel displays the parameter value inthe SYMBOLICS Table field highlighted next:


Command ===>














PITR Journal Grp..

SYMBOLICS Table...


� �


6.11 Parmlib Data Set

6.11 Parmlib Data Set

This library contains the Type Sequence member, if one is defined at your site.To allocate the Parmlib data set, the administrator edits the BC1JEPRMmember in the site's CA Endevor JCLLIB data set, and then executes the batchjob. To define the Parmlib data set to CA Endevor, the administrator adds thePARMLIB= parameter to the C1DEFLTS table.

Defining the Parmlib in the C1DEFLTS: The PARMLIB= parameter must beadded to the C1DEFLTS table. In the following example, the Parmlib data setname is BST.ENDEVOR.PARMLIB. This example also shows that the typesequence member is named ETYPESEQ.

Col 1 Col 16 Col 72


.

.

.

PARMLIB='BST.ENDEVOR.PARMLIB', X

TYPESEQMBR=ETYPESEQ, X

.

.

.

The environment site information panel displays Parmlib information on thesecond screen of the Site Information from C1DEFLTS panel. The followingpanel shows that the Parmlib data set contains the type sequence file:

� �---------------------- Site Information from C1DEFLTS -------------------------

Command ===>

------------------------- Package Processing Options -------------------------

Approval Required..... Y Cast Security......... N Security.. ESI

Foreground Execution.. Y Component Validation.. O

High-level Index for Generated Remote Pkg Ship JCL...

--------------------------- Control Data Set Names ---------------------------

Element Catalog............ BST.DEVEL.ELMCATL

Package Control File....... BST.DEVR4�.VSAMRLS.PACKAGE

Installation Macro Library. BST.P4�B4�S2.MACLIB

CCID Validation Data Set...

ACM Index Root Data Set.... BST.NDVR4��.ACMROOT

ACM Index Xref Data Set.... BST.NDVR4��.ACMXREF

------------------------ Endevor Parmlib Information ------------------------Endevor Parmlib Data Set... BST.ENDEVOR.PARMLIB

Type Sequence Mbr...... ETYPESEQ


� �


6.12 Type Sequence

6.12 Type Sequence

Use this option to enable Global Type Sequencing at your site. With thisoption enabled, SCL and API element actions are executed in type sequenceorder defined at the site level.

6.12.1 Implementing Global Type SequencingTo implement Global Type Sequencing, the CA Endevor admistrator creates atype processing sequence file. The order of the type records in the TypeSequence member represents the processing sequence.

To assist in building the Type Sequence member, a utility helps theadministrator to define type sequencing for the site. After the file is in thedesired order, the administrator copies the file to the site's Type Sequencemember file within Endevor's Parmlib data set. To define the Type Sequencefile to CA Endevor, the administrator adds TYPESEQMBR= to the C1DEFLTStable.

For details on creating the type sequence file, see the chapter "Global TypeSequencing."

6.12.2 Defining the Type Sequence Member in the C1DEFLTSThe TYPESEQMBR= parameter must be added to the C1DELTS table. Fordetails about defining the TYPESEQMBR= parameter in the C1DEFLTS, seeDefining the Parmlib in the C1DEFLTS in this chapter. Note that in order toimplement type sequencing, the PARMLIB= parameter must be defined,because the Type Sequence file is contained in the PARMLIB data set.


Chapter 7. Site Symbolics

This chapter describes site symbolics.

Chapter 7. Site Symbolics 7-1



Site-defined symbolics are user-defined symbolic values that you referencewithin dataset name specifications for base, delta, source output, includelibraries, and processors (that is, you can use them wherever you can useEndevor symbolics).


7.2 Site Symbolics Overview


The site symbolics facility enables you to define global symbols that can beused in type and processor definitions to reference data set name specificationsfor base, delta, source output, include libraries, and processors (that is, you canuse them wherever you can use Endevor symbolics). Thus, commonlyreferenced data sets can be defined in a single location significantly easingmaintenance. At execution time, all site symbolics referenced by a processorare stored with the processor symbolics in the component data. If a sitesymbolic is also specified as a processor symbolic, the processor symbolic (andprocessor symbolic override) take precedence.

When Endevor is initialized, the site symbolics are placed into memory. WhenEndevor is terminated, the site symbolic storage is released. If more than oneEndevor task is executing, each task has its own discrete site symbolic storage.

To implement site symbolics, you must define the symbolic and its data valuein a table that is assembled and linked into an authorized load library. Oncethis is done, you must update the SYMBOLTBL parameter in the C1DEFLTStable with the name of the site symbolics table. These actions are describednext.

Note: Site symbolics are required only if you are using USS HFS path namespecifications for element type base or source output file definitions.Otherwise, site symbolics are optional.

7.2.1 Defining Site SymbolicsBefore defining the site symbolics, remember the following:

■ Site symbolic names must begin with a "#".

■ Site symbolic names can contain up to twelve characters, including the "#".

■ The symbolic value may be up to seventy characters long.

■ Site symbolics are referenced with an ampersand preceding the symbolicname. For example, site symbolic #VENDORLB is referenced as:

&#VENDORLB

■ SYMDATA values must be enclosed in quotes if the value containsampersands or quotes. For example:

the value '&&C1SU' sets a value of &C1SU

or

the value 'CICS(''SP''),NODBCS' sets a value of CICS('SP'),NODBCS



■ Quotes or ampersands imbedded in the SYMDATA value must bedoubled. For example:

the value '&&C1SU' sets a value of &C1SU

or

the value '&&&&C1SU' sets a value of &&C1SU

or

the value 'CICS(''SP''),NODBCS' sets a value of CICS('SP'),NODBCS

Use the following format to define a symbolic and its data value in the sitesymbolics table:

$ESYMBOL SYMNAME=#symbolname,SYMDATA=symbolvalue

symbolnameThe symbol name must begin with the # character and is 1 to 11 charactersin length. The # indicates that the symbol is defined in the site-definedsymbolics table.

symbolvalueThe data value associated with the site symbolic is 1 to 70 characters inlength, with no restrictions on the content of the data. If you do notspecify a data value for a symbolic, Endevor treats it as a null variable.

Use the JCL member contained in member BC1JSYMT to create the sitesymbolics table.

7.2.2 Updating C1DEFLTSAfter creating the symbolics table, update C1DEFLTS to reflect the table name.Use the SYMBOLTBL= parameter to define the table name, as shown next:

SPFEDIT=SPFEDIT, X

SYMBOLTBL=ESYMBOLS, X

SYSIEWL=SYSIEWLP, X

MIXEDFMT=(DESCRIPTION,COMMENT), X

UIDLOC=(1,7), X

VIOUNIT=VIO, X

WRKUNIT=SYSDA, X

RACFUID=NDVUSER, X

RACFGRP=NDVALT�, X

PKGCSEC=N, X

PKGCVAL=O, X

PKGSEC=ESI, X

PRBLKSZ=��, X

PRLNKSZ=(896K,96K), X

PRLSTSZ=1�, X

MODHLI=CA


ENVNAME=TSTSMPL X

ENVTITL='Endevor Administraion Application'. X



The Site Information from C1DEFLTS panel displays the parameter value inthe SYMBOLICS Table field, as shown next:


Command ===>














PITR Journal Grp..

SYMBOLICS Table...


� �

These are the site symbolics defined in your system.

� � DISPLAY ---------------- SYMBOL TABLE: ESYMBOLS ------------ Row 1 to 6 of 6


SYMBOL VALUE

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

#ENDEVOR CA.Software.Endevor

#PERMBASE1 /u/endevor/sampltest/admin/base


� �


Chapter 8. Using CCIDs

Change Control Identifiers (CCIDs) provide Endevor users with an importantproject management tool. CCIDs can function as logical grouping mechanismsby which user-specified portions of the Endevor inventory can be tagged, thenviewed, tracked, and manipulated.

In addition to the CCID, you can also specify a comment for Endevor actions.Consider using the comment as well as the CCID to provide additionalinformation. For instance, the person who performs an action might use theCOMMENT field to note the purpose of the action.

Users can specify CCIDs and/or comments when they request actions. Youcan decide whether or not to require CCIDs and/or comments for all actionrequests on a system-by-system basis.

You can specify a CCID and/or comment when you request any of theseEndevor actions: ADD, UPDATE, RETRIEVE, GENERATE, MOVE,TRANSFER, DELETE, and RESTORE. Endevor updates the CCID and/orcomment in up to six places with the CCID and/or comment specified in theaction request. Whether a CCID and/or comment is updated depends on theeffect the action has on the source and outputs managed by Endevor.

Chapter 8. Using CCIDs 8-1

8.1 What CCIDs and/or Comments Indicate

8.1 What CCIDs and/or Comments Indicate

This section describes the six CCID and/or Comment fields.

Six Fields: The six CCID and/or COMMENT fields that may be updated arelisted next, along with an explanation of the information provided by each pairof fields on the list:

Field Description

Last Action CCIDand/or comment

The CCID and/or comment used the last time anyaction was performed that updated Endevor in anyway (every action except RETRIEVE). This CCIDand/or comment is stored in the Master Control File.

Current Source CCIDand/or comment

The CCID and/or comment used the last time anEndevor action changed the source. This CCIDand/or comment is stored in the Master Control File.

Generate CCIDand/or comment

The CCID and/or comment used the last time anEndevor action caused output processing to occur.Output processing occurs when a processor is run oran output data set is updated. This CCID and/orcomment is stored in the Master Control File.

Retrieve CCIDand/or comment

These fields only reflect the CCID and/or commentused during the RETRIEVE action if the last action atthat stage was RETRIEVE. This CCID and/orcomment is stored in the Master Control File.

Viewing this information allows you to determinewhich elements have been retrieved for update by aparticular project.

Source Delta CCIDand/or comment

Each delta level contains the CCID and/or commentspecified in the action that created the delta level.

Component ListDelta CCID and/orcomment

Each component list delta level contains the CCIDand/or comment specified in the action that createdthe delta level.


8.2 Requiring CCIDs

8.2 Requiring CCIDs

During Endevor implementation you should decide whether to require CCIDand/or comments.

8.2.1 ProcedureYou can require the use of CCIDs and/or comments on a system-by-systembasis. To require CCIDs and/or comments for a given system, perform thefollowing steps:

1. Select option 3 on the Environment Options Menu and press Enter.Endevor displays the System Request panel.

2. Type U in the COMMAND field, enter the environment name in theENVIRONMENT field, and press Enter. Endevor displays the SystemDefinition panel.


COMMAND ===>





GENERAL OPTIONS:













� �

3. Enter Y in the CCID and/or COMMENT fields, and press Enter to saveyour changes.


8.2 Requiring CCIDs

8.2.2 Action Prompt PanelIf you do not specify a CCID and/or comment when one or the other isrequired for an action you are requesting, Endevor displays the Action Promptpanel.

� �-------------------------------- ACTION PROMPT -------------- COMMENT REQUIRED

COMMAND ===>

Specification Required:

CCID: Y (Y/N)

COMMENT: Y (Y/N)

Action: GENERATE Element: FAPCOB�1

Environment: SMPLTEST System: ADMIN Subsystem: ACCTPAY

Type: COBOL Stage: TEST

CCID ===>

COMMENT ===>

� �

To complete your action request, type a valid CCID and/or comment on thisscreen and press Enter.


8.3 When Endevor Updates CCID Fields


You can specify a CCID and/or a comment when requesting Endevor toperform the following actions:

■ ADD

■ UPDATE

■ RETRIEVE

■ GENERATE

■ MOVE

■ TRANSFER

■ DELETE

■ RESTORE

Endevor uses the CCID and/or comment that you specify for the action toupdate one or more of the following fields:

■ Master Control File fields:

– CURRENT SOURCE CCID and/or COMMENT

– GENERATE CCID and/or COMMENT

– RETRIEVE CCID and/or COMMENT

– LAST ACTION CCID and/or COMMENT

■ SOURCE DELTA CCID and/or COMMENT

■ COMPONENT LIST DELTA CCID and/or COMMENT

The fields that Endevor updates depend on the action you specify. Thefollowing sections on specific actions provide details on which of the CCIDand/or COMMENT fields are updated, and under what circumstances. For acomplete description of each action, see the User Guide.

8.3.1 Add Action CCID UpdatesWhen you specify a CCID and/or comment in an ADD action, Endevorupdates CCID and/or COMMENT fields differently depending on whetheryou are adding a new element or an existing element.



8.3.1.1 Specifying an Add Action for a New Element

When you specify a CCID and/or comment in an ADD action for a newelement, Endevor uses this CCID and/or comment to set the following fields:

■ LAST ACTION CCID and/or COMMENT fields.

■ CURRENT SOURCE and SOURCE DELTA CCID and/or COMMENTfields.

■ GENERATE and COMPONENT LIST DELTA CCID and/or COMMENTfields if the generate processor is run.

In addition, the first time an element is added to Endevor the commentspecified is stored separately. This comment appears in the ELEMENTDESCRIPTION field of the Master Control File display, and remains with theelement as long as it resides in Endevor.

8.3.1.2 Specifying an Add Action for an Existing Element

When you specify a CCID and/or comment in an ADD action for an existingelement, Endevor uses this CCID and/or comment to set the following fields:


■ CURRENT SOURCE and SOURCE DELTA CCID and/or COMMENTfields if the element has changed.

■ GENERATE CCID and/or COMMENT fields if the generate processor isrun.

■ COMPONENT LIST DELTA CCID and/or COMMENT fields if thecomponent list has changed.

Endevor also clears the Stage 1 RETRIEVE CCID and/or COMMENT fieldswhen you add an existing element.

CAUTION:If you specify the BYPASS GENERATE PROCESSOR option, the ADDaction will not set the generate or component list delta CCID and/orCOMMENT fields.

8.3.2 Update Action CCID UpdatesWhen you specify a CCID and/or comment in an UPDATE action for anexisting element, Endevor uses this CCID and/or comment to set the followingfields:


■ CURRENT SOURCE and SOURCE DELTA CCID and/or COMMENTfields if the element has changed.



■ GENERATE CCID and/or COMMENT fields if the generate processor isrun.

■ COMPONENT LIST DELTA CCID and/or COMMENT fields if thecomponent list has changed.

Endevor also clears the Stage 1 RETRIEVE CCID and/or COMMENT fieldswhen you UPDATE an element.

CAUTION:If you specify the BYPASS GENERATE PROCESSOR option, the UPDATEaction will not set the generate or component list delta CCID and/orCOMMENT fields.

8.3.3 Retrieve Action CCID UpdatesWhen you specify a CCID and/or comment in a RETRIEVE action for anexisting element, Endevor uses this CCID and/or comment to set theRETRIEVE CCID and/or COMMENT fields.

8.3.4 Generate Action CCID UpdatesWhen you specify a CCID and/or comment in a GENERATE action, Endevorupdates CCID and/or COMMENT fields differently depending on whetheryou specify the GENERATE action with or without copyback.

8.3.4.1 Specifying a Generate Action without Copyback

When you specify a CCID and/or comment in a GENERATE action withoutcopyback, Endevor uses this CCID and/or comment to set the following fields:


■ GENERATE CCID and/or COMMENT fields.

■ COMPONENT LIST DELTA CCID and/or COMMENT fields if runningthe generate processor causes the component list to change.

8.3.4.2 Specifying a Generate Action with Copyback

When you specify a CCID and/or comment in a GENERATE action withcopyback, Endevor uses this CCID and/or comment to set the following fields:

■ LAST ACTION CCID and/or COMMENT fields at the generate location.

■ GENERATE and COMPONENT LIST DELTA CCID and/or COMMENTfields at the generate location.

Endevor also sets current source and source delta CCID and/or COMMENTfields to the value associated with the element that is copied back.



8.3.5 Move Action CCID UpdatesWhen you specify a CCID and/or comment in a MOVE action, Endevorupdates CCID and/or COMMENT fields differently depending on whetheryou specify the MOVE action with history or without history.

8.3.5.1 Specifying a Move Action without History

When you specify a CCID and/or comment in a MOVE action without history,Endevor uses this CCID and/or comment to set the LAST ACTION CCIDand/or COMMENT fields. Endevor also performs the following actions:

■ Sets the target CURRENT SOURCE and GENERATE CCID and/orCOMMENT fields to their value at the starting location of the MOVE.

■ Sets the target SOURCE DELTA and COMPONENT LIST DELTA CCIDand/or COMMENT fields to their last value at the starting location of theMOVE.

■ Clears the RETRIEVE CCID and/or COMMENT fields.

8.3.5.2 Specifying a Move Action with History

When you specify a CCID and/or comment in a MOVE action with history,Endevor uses this CCID and/or comment to set the LAST ACTION CCIDand/or COMMENT fields. Endevor also performs the following actions:

■ Sets the CURRENT SOURCE and GENERATE CCID and/or COMMENTfields to their start location value.

■ Moves SOURCE DELTA and COMPONENT LIST DELTA CCIDs andCOMMENTs with their respective delta levels.


8.3.6 Transfer Action CCID UpdatesWhen you specify a CCID and/or comment in a TRANSFER action, Endevorupdates CCID and/or COMMENT fields differently depending on whetheryou specify the TRANSFER request without history, with history, or withsynchronization.

8.3.6.1 Specifying a Transfer Action without History

When you specify a CCID and/or comment in a TRANSFER action withouthistory, Endevor uses this CCID and/or comment to set the following fields:





Endevor also:

■ Sets the CURRENT SOURCE CCID and/or COMMENT fields from theirvalue in the previous stage.

■ Sets the SOURCE DELTA CCID and/or COMMENT fields from their lastdelta value in the previous stage.


8.3.6.2 Specifying a Transfer Action with History

When you specify a CCID and/or comment in a TRANSFER action withhistory, Endevor uses this CCID and/or comment to set the following fields:



Endevor also performs the following actions:

■ Sets the CURRENT SOURCE CCID and/or COMMENT fields from theirvalue in the previous stage.

■ Moves SOURCE DELTA CCIDs and COMMENTs with their respectivedelta levels.


When you specify SYNCHRONIZE along with the TRANSFER WITHHISTORY option, Endevor creates a synchronize source delta level. WhenEndevor creates this synchronize delta level, it performs the following actions:

■ Sets the CCID and/or COMMENT fields from the base value.

■ Sets the synchronize flag to indicate that this source delta level was createdas a result of the synchronize option.

CAUTION:If you specify the BYPASS GENERATE PROCESSOR option, theTRANSFER action will not set the generate or component list delta CCIDand/or COMMENT fields.

8.3.7 Delete Action CCID UpdatesIf you specify a CCID and/or comment on a DELETE action, that CCIDand/or comment is logged to SMF (if SMF logging is being performed). TheCCID and/or comment is available to Endevor exits.



8.3.8 Restore Action CCID UpdatesWhen you specify a CCID and/or comment in a RESTORE action for anexisting element, Endevor uses this CCID and/or comment to set the followingfields:



Endevor sets the CURRENT SOURCE, SOURCE DELTA, and RETRIEVE CCIDand/or COMMENT fields based on the contents of the archive data set fromwhich you restore.

CAUTION:If you specify the BYPASS GENERATE PROCESSOR option, the RESTOREaction will not set the generate or component list delta CCID and/orCOMMENT fields.

8.3.9 Summary CCID Impact ChartThe following chart summarizes the impact of Endevor actions on the six fieldsthat each action may update with the CCID and/or comment information thatyou specify for the action:

Action CurrentSourceCCID/Comment

GenerateCCID/Comment

LastActionCCID/Comment

RetrieveCCID/Comment

Source DeltaCCID/ Comment

Component CCID/Comment

Add (newelement)

Set Set ifchanged

Set Set Set if generated

Add(existingelement)

Set ifchanged

Set ifgenerated

Set Set Set if generatecreates a delta

Update Set ifchanged

Set ifgenerated

Set Set if changed Set if generatecreates a delta

Retrieve Set

Generatewithoutcopyback

Set Set Set if generatecreates a delta

Generatewithcopyback

Set tocopiedbackvalue

Set Set Set to copiedback value

Set



Action CurrentSourceCCID/Comment

GenerateCCID/Comment

LastActionCCID/Comment

RetrieveCCID/Comment

Source DeltaCCID/ Comment

Component CCID/Comment

Signin Clear

Delete

Restore Set fromArchive

Set ifgenerated

Set SetfromArchive

Set from Archive Set if generated

Archive

Movewithouthistory

Set fromstartlocationvalue


Set Clear Set from last startlocation deltavalue

Set from last startlocation delta value

Movewithhistory



Set Clear Carried withdelta levels

Carried with deltalevels

Transferwithouthistory

Set frompreviousstagevalue

Set ifgenerated

Set Clear Set from lastdelta valueprevious stage

Set if generated

Transferwithhistory


Set ifgenerated

Set Clear Carried withdelta levels

Set if generated

TransferwithSYNC


Set ifgenerated

Set Clear Set from basevalue. Carriedwith delta levels+ on SYNC level

Set if generated


8.4 Predefining CCIDs


Predefining CCIDs allows you to perform the following:

■ Validate CCIDs entered by users against the predefined CCIDs.

■ Associate user IDs or specific inventory areas with certain CCIDs.

You can predefine CCIDs in one of the following ways:

■ Define a CCID definition data set within Endevor.

■ Use a product such as IBM's Information/Management Facility; Endevorprovides an interface for this product.

■ Create your own file; Endevor provides a user exit capability so you candefine your own CCID definition file.

This section contains information about CCID validation in Endevor and aboutthe CCID definition data set that you can define within Endevor.

8.4.1 CCID ValidationIf you have predefined CCIDs, the CCID definition file is read into memory atEndevor start-up. Any changes made to the definition file during an Endevorwork session will not take effect until you exit Endevor and then re-enter thesystem.

CCID validation processing takes effect at the time an action is performed.That is, a batch action could be built (using the batch or package constructionscreens), but denied at execution time.

CCID validation occurs only if a CCID is specified. If the system you areworking with has not been defined with CCID required and you do notspecify a CCID, CCID (and project) validation is bypassed. If you specify aCCID for an action (whether or not it is required by the system), CCIDvalidation is performed.

CCID validation applies only to specific actions. This processing is notapplicable with the LIST or PRINT actions, as you cannot specify a CCID forthese actions.

Note: CCID validation performed by Endevor can be used as a secondaryvalidation mechanism that is invoked if a no match condition is found in theEndevor Information/Management Interface. For more information, see theInterface for IBM Tivoli Information Management Administration Guide.



8.4.2 Endevor CCID Definition Data SetYou can define and maintain CCIDs in a sequential file that you identify in theDefaults Table. This file is optional. It allows you to predefine CCIDs andassociate each CCID, if you choose, with user IDs and/or Endevor inventoryareas.

When a CCID is specified in an Endevor action, Endevor validates that CCIDagainst the contents of this data set. It determines whether or not the user isauthorized to use the specified CCID in conjunction with the inventory areaagainst which the action is being performed.

You must maintain the definition file using either the ISPF (or any other) texteditor or by creating the file from your existing project management system.The definition file must be a card-image data set (80-byte, fixed-formatrecords).

The format of the records in the CCID definition file is variable; the recordsmay be comments ("comment lines") or definitions ("definition lines"). CCIDsare required on every definition line; optionally, a TSO user and/or Endevorelement identification information (environment, system, subsystem, elementname, type, and stage) can be given.

8.4.2.1 Creating a CCID Definition Data Set

Follow these steps to create a CCID definition data set:

1. Specify a CCID data set name in the Defaults Table

2. When you create the sequential file, be sure to specify a data set name inthe format: project.dataset.type

where type is a unique value. This causes the ISPF editor to use a uniqueprofile for the data set.

3. Allocate that data set (using standard ISPF data set utilities).

4. Initialize the data set by copying member SAMPCIPO from theiprfx.iqual.JCLLIB library into the allocated data set.

SAMPCIPO is a sample CCID definition data set that is distributed withthe Endevor system. You can use SAMPCIPO to build a data setappropriate to the needs of your organization

For details, see the Getting Started guide.



8.4.2.2 The Purpose of a Sequential Data Set

There are two reasons why a sequential data set is used for CCID definition:

■ A sequential data set allows you to use the standard ISPF text editor forediting.

■ A sequential data set allows you to off-load project managementinformation from an existing application (such as IBM'sInformation/Management system) and construct the data set using anapplication program.

Note: To assist in the building of the application program, an assemblermacro has been supplied with the system. The macro can be found in theinstallation source library (iprfx.iqual.SOURCE) built during Step 1 of theEndevor installation process (For details, see the Getting Started guide). Themember name of the macro is $CIPOREC.

If you want to write a program to create a CCID definition data set, use therecord layout specified in $CIPOREC, using your own data.

8.4.2.3 Editing the File Using the ISPF Text Editor

Setting up a CCID definition file as a sequential file allows you to use the ISPFtext editor to edit the file, as follows.

First, enter the following primary commands:

TABS ON; CAPS ON; NULLS OFF

Second, set your tab positions as follows:

* * * * * * * *

3 16 25 34 36 45 54 63

8.4.3 Using the CCID Definition Data SetThe CCID definition data set can be used for the following:

■ To register the names of CCIDs. The CCID definition data set can alsocontain user and/or element identification data.

■ As a secondary or backup CCID validation mechanism, in conjunctionwith the Information/Management interface.

If a CCID gets a "no match" condition from the Information/Managementinterface, Endevor uses the CCID definition data set to check further. Ifthe interface recognizes the CCID, then Endevor bypasses the CCID check.



Using the CCID definition feature with this additional information can assistyou in project management. You can create multiple lines in the CCIDdefinition data set for each valid CCID. For a given CCID value, thesesuccessive lines specify either the users allowed to work under this CCID, theinventory items/areas which may be worked on, or both.

For example, assume that a site has two projects: TAX-CHNG-89 andNEW-COMPPLAN. Only people in the Development Department (TSO userIDs: DEVxxx) are allowed to perform changes as part of these projects. Theinventory areas for the changes are as follows:

■ Environment = DEMO

■ Stage number = 1

■ Systems for TAX-CHNG-89 = PAYROLL and ACCOUNTG

■ Systems for NEW-COMPPLAN = PAYROLL and PERSONEL

The CCID definition file would be coded as:

card

position 3 16 25 34 36 45 54 63

� CCID USERID ENVIRON # SYSTEM SUBSYS TYPE ELEMENT

TAX-CHNG-89 DEV� DEMO 1 PAYROLL

TAX-CHNG-89 DEV� DEMO 1 ACCOUNTG

NEW-COMPPLAN DEV� DEMO 1 PAYROLL

NEW-COMPPLAN DEV� DEMO 1 PERSONEL

Sample CCID Definition Data Set: A sample CCID definition data set isshown next:

card

position 3 16 25 34 36 45 54 63

� CCID USERID ENVIRON # SYSTEM SUBSYS TYPE ELEMENT

AC-DEV-89/�2 ZSXBAP1 DEMO 1 ACCOUNTG

MA-DEV-89/�2 ZSX� DEMO 1 MANUFACT

PE-DEV-89/�2 ZSXJMH1 DEMO 1 PERSONEL

PE-DEV-89/�2 ZSXPGM1 DEMO 1 PERSONEL

PE-DEV-89/�2 ZSXSXV1 DEMO 1 PERSONEL

QA-89/�2 ZSXREL1 DEMO 2 � � � �

EMERGNCY-FIX 2

The following coding conventions apply to this data set:

■ Any line that begins with an asterisk (*) in column 1 is considered acomment line.

■ Every non-comment line is considered a definition line, and must specify aCCID. The CCID field is always required.



■ All other fields on a definition line are optional. If any field is left blank(such as the SUBSYSTEM field for the first five lines listed in the previoussample), it is ignored.

■ Name masks (for example, ZSX* or simply * in the previous sample) canbe used in any of the optional fields. Imbedded asterisks are not allowed.

A description of each field in the data set follows:

Field CardPosition

Description

CCID 3 The name of the CCID. The name must befully specified, defining a valid CCID. Thisvalue must be specified on every definitionline. The same CCID may appear onmultiple lines.

Userid �1� 16 If used, only the users whose user ID isspecified (whether by full name or with theuse of a name mask) may use the CCIDindicated on this line.

Environ �1� 25 Environment name. If used, only elementsin the environment specified (whether byfull name or with the use of a name mask)can be updated under the CCID indicatedon this line.

# �1� 34 Stage number. If used, only elements inthe stage specified (either 1, 2, or *) can beupdated under the CCID indicated on thisline.

System �1� 36 System name. If used, only elements in thesystem specified (whether by full name orwith the use of a name mask) can beupdated under the CCID indicated on thisline.

Subsys �1� 45 Subsystem name. If used, only elements inthe subsystem specified (whether by fullname or with the use of a name mask) canbe updated under the CCID indicated onthis line.

Type �1� 54 Element type. If used, only elements of thetype specified (whether by full name orwith the use of a name mask) can beupdated under the CCID indicated on thisline.



Field CardPosition

Description

Element �1� 63 Element name. If used, only elementswhose names are specified (whether by fullname or with the use of a name mask) canbe updated under the CCID indicated onthis line.

Note: �1�: These fields are optional.


Chapter 9. SMF Recording

If the SMF interface is implemented at your site (as described in the GettingStarted guide), Endevor can write out SMF records during operation as follows:

■ For each security violation — or each error returned from the security exit(exit 1, described in Getting Started guide) — Endevor can write out anSMF Security Record.

■ For each action executed, Endevor can write out an appropriate SMFAction Record at the end of action processing. Exceptions are the SIGNIN,PRINT, DISPLAY, COPY, and LIST actions, for which SMF recording doesnot apply.

Endevor writes out SMF records if requested during installation, through theDefaults Table. It writes Security Records if the Defaults Table specifiesSMFSEC=Y, and it writes Action Records if the Defaults Table specifiesSMFACT=Y. (A third Defaults Table option, SMFENV, is not supported withthis release of the software.) SMF records are specific to an environment. Forexample, you might request SMF records for one environment but not another.For details about the Defaults Table, see the Getting Started guide.

Notes:

■ Within this chapter, any discussion of SMF Security Records assumes youare working with the native security facility. If the optional ExternalSecurity Interface (Endevor ESI) is installed at your site, see the SecurityGuide for related information.

■ Any of your pre-release 4.0 programs that read the SMF records created byEndevor may need some source changes, but must at least be reassembledand linked in order to incorporate modifications made for release 4.0.

Chapter 9. SMF Recording 9-1

9.1 Record Formats

9.1 Record Formats

Endevor uses several blocks to build the SMF Security and Action Records,each comprising one or more DSECTs. All DSECTs are supplied iniprfx.iqual.SOURCE.

Each SMF record output by Endevor starts with a standard SMF header block(DSECT $SMFHDDS), which contains fields required by SMF, as well as theenvironment and user names for the element being processed. Endevorrecords can be identified by the record type field in the header block(SMHRECTY), which is defined in the Defaults Table for each site (230 bydefault). This field is the same for each Endevor SMF record, and identifiesthe records as being specific to Endevor.

Following the header block, each record has a data block that is specific to therecord type:

■ DSECT $SMFREC1 for Security Records

■ DSECT $SMFREC2 for Action Records

For Action Records, the $SMFREC2 block encompasses one or moreaction-specific blocks, as described next. For a detailed description of eachDSECT used to format SMF records, see 9.2, “DSECT Descriptions” onpage 9-5.

9.1.1 SMF Security RecordsSMF Security Records include data specific to the security violation beingreported. The data block for Security Records is written out using DSECT$SMFREC1. The combined format for SMF Security Records, then, is describedusing the following DSECTs:

■ $SMFHDDS

■ $SMFREC1


9.1 Record Formats

9.1.2 SMF Action RecordsSMF Action Records include data specific to the action being reported, andapply for all actions except PRINT, DISPLAY, COPY, and LIST. Each ActionRecord has one occurrence of the $SMFREC2 DSECT, and one or moreaction-specific blocks from the $SMFBKDS DSECT, as appropriate to theaction. Each action-specific block has an action-block header (DSECT$SM2BHDDS), and either the type 1, 2, 3, or 4 action-block detail information(respectively, DSECT SM2ENVDS, SM2LCGDS, SM2LPRDS, or SM2REQDS,described next, and identified separately in 9.2.4, “$SMFBKDS DSECT:Action-Specific Blocks” on page 9-13.).

The combined format for SMF Action Records, then, is described using thefollowing DSECTs:

■ $SMFHDDS

■ $SMFREC2

■ $SMFBKDS action-block header

■ $SMFBKDS action-block detail (type n)

■ $SMFBKDS action-block header

■ $SMFBKDS action-block detail (type n)(includes up to five action blocks)


9.1 Record Formats

There are four different types of action-block detail information, each having adifferent format, or DSECT (within the $SMFBKDS DSECT). Each formatapplies to specific actions, described briefly as follows. Where two occurrencesof a DSECT are used by an action, "(2)" follows the action name, below.

ActionBlockDetailType #

DSECTType

Actions Description

1 Environment(SM2ENVDS)

Add (2)Update (2)Retrieve (2)GenerateMove(2)DeleteTransfer (2)Archive (2)Restore (2)

Information describing theenvironment where the actiontook place: name of theenvironment, site ID, etc.Where two blocks are used, onerepresents the sourceenvironment for the element,while the other represents thetarget environment.

2 Last Change(SM2LCGDS)

AddUpdateGenerateMoveDeleteTransferRestore

Information describing the lastaction (the action beingrecorded): date and time of theaction, comments describing theaction, and so forth.

3 ProcessorInfo(SM2LPRDS)

AddUpdateGenerateMoveDeleteTransferRestore

Information about the lastprocessor executed: processorname, date and time ofexecution, etc. Used for actionsthat can invoke a processor.

4 RequestParameterInfo(SM2REQDS)

All actions General information about theaction: CCID, comments, and soforth.


9.2 DSECT Descriptions


This section describes each of the DSECTs used to write out SMF Action andSecurity Records. In cases where specific fields are not applicable for thecurrent processing, alphabetic fields are space-filled and numeric fields arezero-filled.

9.2.1 $SMFHDDS DSECT: SMF Header BlockThe header block is written at the beginning of each SMF record. EndevorSecurity and Action Records can be identified by the record type field in theheader, SMHRECTY, which has the same value in every Endevor SMF record.This value is defined in the Defaults Table (defaults to 230).

$SMFHDDS

$SMFHDDS DSECT

$SMFHDDS DS �D ALIGN IT

��

� �

� $SMFHDDS - HEADER FOR THE SMF RECORDS FOR ENDEVOR-C1 �

� �

��

SMHLEN DS H LENGTH OF THE OVERALL RECORD

SMHSEGID DS H �� RESERVED ��

SMHSID DS XL1 SYSTEM TYPE ID

SMH$VS2 EQU X'�2' VS2 INDICATOR

SMH$VS1 EQU X'�1' VS1 INDICATOR

SMHRECTY DS XL1 SMF RECORD TYPE ( DEFAULT 23�)

SMH$23� EQU 23� SMF RECORD TYPE DEFAULT

SMHTIME DS XL4 TIME IN HUNDREDTHS OF A SECOND

SMHDATE DS XL4 DATE

SMHCPUID DS CL4 CPU FROM SYSTEM WRITING RECORD

SMHHDLEN DS H LENGTH OF THIS HEADER

SMHC1VER DS X ENDEVOR-C1 RECORD FORMAT VERSION

SMH$RF�� EQU X'��' RELEASE 2.2 AND PRIOR RELEASES

SMH$RF�1 EQU X'�1' RELEASE 2.5 THRU CURRENT

SMHCTLTY DS X ENDEVOR-C1 RECORD SUBTYPE

SMH$SEC EQU X'�1' SECURITY RECORD TYPE

SMH$ACT EQU X'�2' ACTION RECORD TYPE

SMH$ESI EQU X'�3' ESI EXCEPTION WARNING RECORD

SMH$ENV EQU X'�4' ENVIRONMENT MCF CHANGES

SMH$MAX EQU SMH$ENV �� MAX RECORD NUM DEFINED ��

SMHCONT DS H CONTINUATION FLAG FOR RECORD

SMHSEQ DS H SEQUENCE NUMBER OF RECORD

SMHC1ENV DS CL8 ENDEVOR-C1 ENVIRONMENT NAME

SMHUSER DS CL8 USER ISSUING REQUEST

DS �D

SMHSIZE EQU �-$SMFHDDS SIZE OF THE HEADER ( FOR SMHHDLEN)

SMHDATA EQU � START OF THE DATA

MEND



SMF Header Block Field Descriptions: The following table describes theSMF header block fields:

Field Description

SMHLEN Size of the (Security or Action) record, in bytes. Thisincludes the size of the header block as well as thedata block:

■ $SMFREC1 — Security Records■ $SMFREC2 (including all action-specific blocks)

— Action Records

SMHSEGID Not used.

SMHSID Operating system against which the SMF record iswritten. Always X'02' with release 3.7.

SMHRECTY Number that identifies this SMF record as specific toEndevor. This number is defined to Endevor throughthe Defaults Table.

SMHTIME Time the SMF record was created (binary time of dayin 100ths of a second — 1 = .01 second).

SMHDATE Date the SMF record was created (packed yyddd).

SMHCPUID Number to identify the CPU model on whichEndevor is running.

SMHHDLEN Size of the header block (DSECT $SMFHDDS), inbytes.

SMHC1VER Code that identifies the format of the SMF record.

■ SMH$RF00 — This record was created byEndevor release 2.2 or a prior release.

■ SMH$RF01 — This record was created byEndevor release 2.5 or a later release.

SMHCTLTY Code that identifies the next record format in theSMF record.

SMHCONT Not used.

SMHSEQ Not used.

SMHC1ENV Environment name associated with the currentprocessing.

SMHUSER User ID associated with the current processing.

SMHSIZE Size of the $SMFHDDS DSECT.



9.2.2 $SMFREC1 DSECT: Security Record Data BlockThis DSECT applies for Security Records, and includes data specific to thesecurity violation being reported.

$SMFREC1

$SMFREC1 DSECT

$SMFREC1 DS �D ALIGN IT

��

� �

� $SMFREC1 - DESCRIPTION FOR THE SECURITY RECORD �

� �

� �

��

SM1REC1 EQU � START OF THE SMF 1 RECORD

SM1RECLN DS H LENGTH OF THE SECURITY RECORD

SM1RECVN DS H VERSION OF THE RECORD

SM1$V1 EQU X'�1' VERSION 1


SM1$CURV EQU SM1$V2 CURRENT VERSION

SM1FUNC DS F FUNCTION CODE ( CURRENT ACTION VERB)

SM1FUNNM DS CL8 FUNCTION NAME

��

� �

� MESSAGE AREA �

� �

��

SM1ERRCD DS CL4 SECURITY MESSAGE CODE

SM1ERRLN DS H LENGTH OF SECURITY MESSAGE

SM1MSGSZ EQU 132 LENGTH OF MESSAGE AREA MAX

SM1ERMSG DS CL(SM1MSGSZ) SIZE OF MESSAGE AREA

��

� �

� ENVIRONMENT INFORMATION �

� �

��

SM1SITE DS CL1 SITE CODE

SM1STGID DS CL1 STAGE ID

SM1STGCD DS CL1 STAGE CODE

SM1IFUNC DS XL2 INTERNAL SECURITY FUNCTION

� SEE ECBFUNC OF $ECBDS FOR LIST OF

� ACTIONS

DS CL3 �� RESERVED ��

SM1ENVM DS CL8 ENVIRONMENT NAME

SM1STAGE DS CL8 STAGE NAME

SM1SYSTM DS CL8 SYSTEM NAME

SM1SUBSY DS CL8 SUBSYSTEM NAME

SM1STYPE DS CL8 TYPE

SM1ELEMT DS CL1� ELEMENT NAME (VERSION 1)

ORG SM1ELEMT VERSION 2

SM1EAOFF DS XL2 V2: ELMT AREA OFFSET FROM $SMFREC1

DS CL8 V2: RESERVED

��



� �

� ASSOCIATED FILE INFORMATION IF ANY �

� �

��

SM1DSNAM DS CL44 ASSOC DATA SET NAME (VERSION 1)

ORG SM1DSNAM VERSION 2: (DSN/PATH)

SM1FAOFF DS XL2 V2: FILE AREA OFFSET FROM $SMFREC1

DS CL42 V2: RESERVED

�

SM1DSMEM DS CL1� ASSOC DATA SET MEMBER (VERSION 1)

ORG SM1DSMEM VERSION 2: (MBR/FILE NAME)

SM1NAOFF DS XL2 V2: NAME AREA OFFSET FROM $SMFREC1

DS CL8 V2: RESERVED

SM1BSIZ EQU �-$SMFREC1 BASE SIZE OF THE RECORD

�

SM1BFAREA DS XL(1�3�) AREA BUFFER SPACE.

�

DS �D

SM1SIZ EQU �-$SMFREC1 SIZE OF THE RECORD

MEND

Security Record Data Block Field Descriptions: The following tabledescribes the fields in the Security Record data block:

Field Description

SM1RECLN Size of this data block (DSECT $SMFREC1), in bytes.

SM1RECVN Version number. Identifies the Endevor release thatcreated the record. Valid values are:

■ 1 — The record was prior to Endevor release 4.0.■ 2 — The record was created by Endevor 4.0.

SM1FUNC Number that identifies the current activity: generallythe type of action. For specific values that apply here,see the definition of field ECBFUNC in the GettingStarted guide.

SM1FUNNM Applicable if SM1FUNC references an Endevoraction. Name of the current action (ADD, UPDATE,etc.).

SM1ERRCD The 4 characters that are used to construct the errorcode written to the Endevor Execution Report for thecurrent action in the ECBMSGCD field, as describedin the Getting Started guide.

The error code is formatted as C1XNNNNS, where:

■ X — Describes the origin of the message.■ NNNN — Defined by this field.■ S — Severity code associated with the return

code field, ECBRTCD, in DSECT $ECBDS.



Field Description

SM1ERRLN Not used.

SM1ERMSG Error message associated with the current activity, asdescribed in Chapter 15, “Performance and Tuning”for the ECBMSG field.

SM1SITE Endevor site ID, as defined to the Defaults Table.

SM1STGID Stage number for the current action request: 1 or 2.

SM1STGCD Applicable if SM1FUNC references an Endevoraction. Stage ID for the current action request.

SM1IFUNC Action information that is used internally byEndevor. For the specific values that apply here, seethe definition of field ECBIFUNC in the GettingStarted guide.

SM1ENVM Environment name for the current processing.

SM1STAGE Applicable if SM1FUNC references an Endevoraction. Stage name for the current action request.

SM1SYSTM Applicable if SM1FUNC references an Endevoraction. System name for the current action.

SM1SUBSY Applicable if SM1FUNC references an Endevoraction. Subsystem name for the current action.

SM1STYPE Applicable if SM1FUNC references an Endevoraction. Element type for the current action.

SM1ELEMT �1� Applicable if SM1FUNC references an Endevoraction. Name of the element specified for the currentaction. row.

SM1EAOFF �2� Element area offset. When the offset is added to thebeginning of the record's address, the resultingaddress points to an area with in the SM1BFAREA.The element area is comprised of two adjacentcomponents:

■ Two byte field containing the length ■ Element name

SM1DSNAM �1� Applicable for security violations that relate to ADD,UPDATE, RESTORE, ARCHIVE, and RETRIEVEaction requests. Data set name associated with theexternal file used by the current action.



Field Description

SM1FAOFF �2� File area offset. When the offset is added to thebeginning of the record's address, the resultingaddress points to an area with in the SM1BFAREA.The file area is comprised of two adjacentcomponents:

■ Two byte field containing the length ■ File name

The file name may be a traditional file or an HFSpath name.

SM1DSMEM �1� Applicable for security violations that relate to ADD,UPDATE, RESTORE, ARCHIVE, and RETRIEVEaction requests. Member name associated with theelement for which the current action applies, withinthe above data set. Applicable when the data set is alibrary.

SM1NAOFF �2� Name area offset. When the offset is added to thebeginning of the record's address, the resultingaddress points to an area with in the SM1BFAREA.The name area consists of two adjacent components:

■ Two byte field containing the length ■ File name

The name may be a member name or an HFS filename.

SM1BSIZ Base size of the record.

SM1BFAREA �2� This is reserved record space containing the variousareas such as element, file and name.

SM1SIZ Size of the $SMFREC1 DSECT.

Note:

�1�: Version 1 records only�2�: Version 2 records only



9.2.3 $SMFREC2 DSECT: Action Record Data BlockThis DSECT applies for Action Records, and includes information specific tothe action being reported. Depending on the action type, one or moreaction-specific blocks (pairs of DSECTs) are incorporated at the end of thisDSECT. For more information, see the discussion of 9.2.4, “$SMFBKDSDSECT: Action-Specific Blocks” on page 9-13.

$SMFREC2

$SMFREC2 DSECT

$SMFREC2 DS �D ALIGN IT

��

� �

� $SMFREC2 - DESCRIPTION FOR THE ACTIVITY RECORD �

� �

��

SM2REC1 EQU � START OF THE SMF 2 RECORD

SM2RECLN DS H LENGTH OF THE ACTIVITY RECORD

SM2RECVN DS H VERSION OF THE RECORD


SM2$CURV EQU SM2$V1 CURRENT VERSION 1

SM2FUNC DS F ACTION CODE


� ACTIONS.

SM2FUNNM DS CL8 FUNCTION NAME

SM2BLKS DS F NUMBER OF BLOCKS IN RECORD

SM2$ENV EQU 1 ENVIRONMENT BLOCK

SM2$LCHG EQU 2 LAST CHANGE BLOCK

SM2$PROC EQU 3 PROCESSOR INFO BLOCK

SM2$REQP EQU 4 REQUEST PARMS BLOCK

SM2RECHD DS H SIZE OF THE SM2 HEADER

SM2IFUNC DS H INTERNAL SECURITY FUNCTION


� ACTIONS.

SM2DATA DS �D

SM2HDRLN EQU �-SM2REC1 OFFSET TO START OF RECORD

DS (SM2LCHLN)CL1 ONE LAST ACTION BLOCK

DS (SM2PRCLN)CL1 ONE PROCESSOR INFO

DS (SM2REQLN)CL1 ONE REQUEST PARM BLOCK

DS (SM2ENVLN)CL1 ENV 1 BLOCK

DS (SM2ENVLN)CL1 ENV 2 BLOCK

DS 1��CL1 EXTRA ROOM

SM2SIZ EQU �-$SMFREC2 SIZE OF THE RECORD

MEND



Action Record Data Block Field Descriptions: The following table describesthe Action Record data block fields:

Field Description

SM2RECLN Size of this data block (DSECT $SMFREC2), in bytes,including all action-specific blocks included at theend (DSECT $SMFBKDS).

SM2RECVN Version number to identify this data block($SMFREC2). This should always be 1. Use theSM2$VERS label to verify that the correct version ofthis DSECT was used:

For example, a value of one with the label SM2$VERSmeans the version for that block is 1.

SM2FUNC Number that identifies the current activity: generallythe current type of action. For specific values thatapply here, see the definition of field ECBFUNC inthe Getting Started guide.

SM2FUNNM Applicable if SM2FUNC references an Endevoraction. Name of the current action (ADD, UPDATE,etc.).

SM2BLKS Count of action-specific blocks included at the end ofthis DSECT: 1-5.

SM2RECHD Size of this data block (DSECT $SMFREC2), in bytes,excluding the action-specific blocks (DSECT$SMFBKDS).

SM2IFUNC Action information that is used internally byEndevor. For the specific values that apply here, seethe definition of field ECBIFUNC in the GettingStarted guide.

SM2HDRLN Size of the $SMFREC2 DSECT, excluding theaction-specific blocks

SM2SIZ Size of the $SMFREC2 DSECT, including allaction-specific blocks incorporated at the end.



9.2.4 $SMFBKDS DSECT: Action-Specific BlocksThis DSECT applies for Action Records, and includes data specific to the actionbeing reported. $SMFBKDS includes five DSECTs — one action-block headerand four action-block detail DSECTs. These DSECTs are used in pairs, witheach pair including a header and one type 1, 2, 3, or 4 detail DSECT. The typeof detailed information included can be identified through the SM2BTYP fieldin the header.

MACRO

&NAME $SMFBKDS &DSCT=YES

��

� �

� $SMFBKDS - DSECTS FOR EACH BLOCK OF SMF2 DATA �

� �

� EACH BLOCK IS PRECEDED BY A HEADER: �

� TYPE 1 - ENVIRONMENT INFORMATION �

� TYPE 2 - LAST CHANGE INFORMATION �

� TYPE 3 - PROCESSOR INFORMATION �

� TYPE 4 - REQUEST PARAMETER INFORMATION �

��

� �

� BLOCK HEADER �

� �

��

AIF ('&DSCT' NE 'YES').NODSCT

SM2BHDDS DSECT

AGO .START

.NODSCT ANOP

SM2BHDDS DS �D ALIGN IT

.START ANOP

SM2BLEN DS H LENGTH OF THE BLOCK

SM2BTYP DS H TYPE OF BLOCK

SM2BVER DS H VERSION OF BLOCK

SM2B$V1 EQU 1 VERSION 1

SM2B$V2 EQU 2 VERSION 2

SM2BFLG1 DS CL1 FLAG 1 FOR BLOCK

SM2BFLG2 DS CL1 FLAG 2 FOR BLOCK

DS �D

SM2BHDR EQU �-SM2BHDDS LENGTH OF HEADER

��

� �

� ENVIRONMENT BLOCK TYPE 1 �

� �

��

AIF ('&DSCT' NE 'YES').NODSCT1

SM2ENVDS DSECT

AGO .START1

.NODSCT1 ANOP

SM2ENVDS DS �D ALIGN IT

.START1 ANOP



DS �D �� START OF HEADER

SM2ELEN DS H LENGTH OF THE BLOCK

SM2ETYP DS H TYPE OF BLOCK

SM2EVER DS H VERSION OF BLOCK (SM2B$V1/V2)

SM2EFLG1 DS CL1 FLAG 1 FOR BLOCK

SM2EFLG2 DS CL1 FLAG 2 FOR BLOCK

DS �D �� END OF HEADER

SM2SITE DS CL1 SITE CODE

SM2STGCD DS CL1 STAGE SELECTION CODE FROM C1DEFLTS

SM2STGID DS XL1 STAGE ID - 1 OR 2


SM2VER DS H VERSION OF THE ELEMENT

SM2LVL DS H LEVEL OF THE ELEMENT

SM2ENVM DS CL8 ENVIRONMENT NAME

SM2STAGE DS CL8 STAGE NAME

SM2SYSTM DS CL8 SYSTEM NAME

SM2SUBSY DS CL8 SUBSYSTEM NAME

SM2STYPE DS CL8 TYPE

SM2ELEMT DS CL1� ELEMENT NAME (VERSION 1)

ORG SM2ELEMT VERSION 2:

SM2EAOFF DS XL2 V2: ELE AREA OFFSET FROM SM2ENVDS

DS CL8 V2: RESERVED

��

� �

� ASSOCIATED FILE INFORMATION IF ANY �

� �

��

SM2DSNAM DS CL44 ASSOC DATA SET NAME (VERSION 1)

ORG SM2DSNAM VERSION 2: (DSN/PATH)

SM2FAOFF DS XL2 V2: FILE AREA OFFSET FROM SM2ENVDS

DS CL42 V2: RESERVED

�

SM2DSMEM DS CL1� ASSOC DATA SET MEMBER (VERSION 1)

ORG SM2DSMEM VERSION 2: (MBR/FILE NAME)

SM2NAOFF DS XL2 V2: NAME AREA OFFSET FROM SM2ENVDS

DS CL8 V2: RESERVED

SM2EBSIZ EQU �-SM2ENVDS ENV BASE SIZE

SM2EAREA DS XL(1�3�) AREA BUFFER SPACE

SM2EDATA DS �D

SM2ENVLN EQU �-SM2ENVDS LENGTH OF ENV BLOCK

��

� �

� LAST CHANGE BLOCK TYPE 2 �

� �

��


SM2LCGDS DSECT

AGO .START2

.NODSCT2 ANOP

SM2LCGDS DS �D ALIGN IT

.START2 ANOP


SM2LLEN DS H LENGTH OF THE BLOCK



SM2LTYP DS H TYPE OF BLOCK

SM2LVER DS H VERSION OF BLOCK (SM2B$V1)

SM2LFLG1 DS CL1 FLAG 1 FOR BLOCK

SM2LFLG2 DS CL1 FLAG 2 FOR BLOCK


SM2CCOM DS CL4� LAST CHANGE COMMENT

SM2MLDTE DS CL6 LAST CHANGE LVL DATE(YYMMDD)

SM2MLTME DS CL4 LAST CHANGE LVL TIME(HHHH)

SM2LUSID DS CL8 LAST LEVEL - USERID

SM2MLACT DS CL8 LAST ACTION


SM2MLTOT DS F LAST LEVEL TOTAL

SM2LDATA DS �D

SM2LCHLN EQU �-SM2LCGDS LENGTH OF LAST CHANGE BLOCK

��

� �

� PROCESSOR INFO BLOCK TYPE 3 �

� �

��


SM2LPRDS DSECT

AGO .START3

.NODSCT3 ANOP

SM2LPRDS DS �D ALIGN IT

.START3 ANOP


SM2PLEN DS H LENGTH OF THE BLOCK

SM2PTYP DS H TYPE OF BLOCK

SM2PVER DS H VERSION OF BLOCK (SM2B$V1)

SM2PFLG1 DS CL1 FLAG 1 FOR BLOCK

SM2PFLG2 DS CL1 FLAG 2 FOR BLOCK


SM2LPRON DS CL1� PROCESSOR NAME

SM2LPROD DS CL6 GENERATE - LAST DATE

SM2LPROT DS CL4 GENERATE - LAST TIME

SM2LPROU DS CL8 GENERATE - LAST USERID

SM2LPHRC DS H GENERATE - HIGHEST RETURN CODE

SM2LPRC1 DS H GENERATE - C1 RETURN CODE

SM2PDATA DS �D

SM2PRCLN EQU �-SM2LPRDS LENGTH OF PROCESSOR BLOCK

��

� �

� REQUEST PARAMETER INFORMATION TYPE 4 �

� �

��


SM2REQDS DSECT

AGO .START4

.NODSCT4 ANOP

SM2REQDS DS �D ALIGN IT

.START4 ANOP


SM2RLEN DS H LENGTH OF THE BLOCK



SM2RTYP DS H TYPE OF BLOCK

SM2RVER DS H VERSION OF BLOCK

SM2R2� EQU � RELEASE 2.2 FORMAT THRU RELEASE 3.�

SM2R35 EQU 1 RELEASE 3.5 FORMAT

SM2CREL EQU 1 CURRENT RECORD FORMAT VERSION

SM2RFLG1 DS CL1 FLAG 1 FOR BLOCK

SM2RFLG2 DS CL1 FLAG 2 FOR BLOCK


SM2RCCID DC CL12' ' CCID ASSOC W/ ACTION

SM2RCOMM DC CL4�' ' COMMENT ASSOC W/ ACTION

SM2RFLAG DC F'�' ANY SPECIAL FLAGS

SM2RSISO DC CL1' ' SIGNIN/SIGNOUT FORCE ( Y OR N)

SM2RSICO DC CL1' ' SIGNIN/SIGNOUT COPY ONLY ( Y OR N)

SM2REXPN DC CL1' ' EXPAND INCLUDES ( Y OR N)

SM2ROVER DC CL1' ' WRITE OVER EXISTING RETR MBR

SM2RRTCD DC F'�' ACTION RETURN CODE

SM2RDEL DC CL1' ' DELETE REQUEST FLAG

� BLANK IF N/A

� Y - YES, DELETE WAS REQUESTED

� N - NO, DELETE WAS NOT REQUESTED

SM2RIGNF DC CL1' ' IGNORE GENERATE FAILED (Y / N)

SM2RBGNP DC CL1' ' BYPASS GENERATE PROCESSOR (Y / N)

SM2RBDLP DC CL1' ' BYPASS DELETE PROCESSOR (Y / N)

SM2RSYNC DC CL1' ' SYNC OPTION SPECIFIED (Y / N)

SM2RONCP DC CL1' ' DELETE ONLY COMPONENTS (Y / N)

SM2RMVWH DC CL1' ' MOVE/TRANSFER W/ HISTORY (Y / N)

SM2RAWUP DC CL1' ' ADD W/ UPDATE OPTION (Y / N)

SM2RPGRP DC CL8' ' PROCESSOUR GROUP OVERRIDE

SM2RSIUS DC CL8' ' SIGNOUT TO USERID

SM2RDATA DS �D

SM2REQLN EQU �-SM2REQDS LENGTH OF PROCESS BLOCK

MEND

Action-Block Header Field Descriptions (SM2BHDDS): The following tabledescribes the fields in action-block header:

Field Description

SM2BLEN Size of this action-specific block (action-block header,SM2BHDDS, plus the action-block detail DSECT), inbytes.

SM2BTYP Code that indicates the DSECT used to write out theaction-block detail for this action- specific block:

SM2BVER Version number to identify this DSECT ($SMFBKDS).This should always be 1 except for the action blockheader. A value of two in this block signifies theblock is created using Endevor 4.0.

SM2BFLG1 Not used.



Field Description

SM2BFLG2 Not used.

SM2BHDR Size of the action-block header ($SM2BHDDS).

9.2.4.1 Environment Action-Block Detail Field Descriptions (SM2ENVDS)

The following table describes the Environment action-block detail fields:

Field Description

SM2SITE Endevor site ID, as defined to the Defaults Table.

SM2STGCD Stage ID for the current action request.

SM13STGID Stage number for the current action request: 1 or 2.

SM2VER Version number associated in the MCF with theelement for the action request.

SM2LVL Number to identify the current level of the elementfor the current action request.

SM2STAGE Stage name for the current action request.

SM2SYSTM System name for the current action request.

SM2SUBSY Subsystem name for the current action request.

SM2STYPE Element type for the current action request.

SM2ELEMT �1� Name of the element specified for the current actionrequest.

SM2EAOFF �2� Element area offset. The element name for thecurrent action request is stored in the buffer arealocated near the end of the record. When the offset isadded to the beginning of this record's address, theresulting address points to an area withinSM2EAREA buffer space. The element area iscomposed of two adjacent components:

■ Two-byte length field ■ Element name

SM2DSNAM �1� Applicable for ADD, UPDATE, RESTORE, ARCHIVE,and RETRIEVE action requests. Data set nameassociated with the external file used by the currentaction.



Field Description

SM2FAOFF �2� File area offset. The file name for the current actionrequest is stored in the buffer area located near theend of the record. When the offset is added to thebeginning of this record's address, the resultingaddress points to an area within SM2EAREA bufferspace. The file area is composed of two adjacentcomponents:

■ Two-byte length field■ Data set name

The file name may be a traditional data set or an HFSpath name.

SM2DSMEM �1� Applicable for ADD, UPDATE, RESTORE, ARCHIVE,and RETRIEVE action requests. Member nameassociated with the element for which the currentaction applies, within the above data set. Applicablewhen the data set is a library; blank otherwise.

SM2NAOFF �2� Name area offset. The member name for the currentaction request is stored in the buffer area located nearthe end of the record. When the offset is added tothe beginning of this record's address, the resultingaddress points to an area within SM2EAREA bufferspace. The name area is composed of two adjacentcomponents:

■ Two-byte length field■ Member name (PDS file) or file name (HFS)

If a member/file name is not applicable to the currentaction, the offset value is set to zero.

SM2EAREA �2� Space reserved in the record containing various datasuch as the element, file and member name.

SM2ENVLN Size of the action-specific block (header and detail) ifthe action-block detail uses the Environment DSECT($SM2ENVDS).

Note:

�1�: Version 1 record only�2�: Version 2 record only



9.2.4.2 Last Change Action-Block Detail Field Descriptions (SM2LCGDS)

The following table describes the Last Change action-block detail fields:

Field Description

SM2CCOM Current-level comment for the element.

SM2MLDTE Current-level date for the element.

SM2MLTME Current-level time for the element.

SM2LUSID Current-level user ID for the element.

SM2MLACT Last action executed for the element.

SM2MLTOT Count of source statements for the element, as of thecurrent level.

SM2LCHLN Size of the action-specific block (header and detail) ifthe action-block detail uses the Last Change DSECT($SM2LCGDS).

9.2.4.3 Processor Information Action-Block Detail Field Descriptions (SM2LPRDS)

The following table describes the Processor Information action-block detailfields:

Field Description

SM2LPRON (Element) name of the processor last run for theelement.

SM2LPROD Processor date for the element.

SM2LPROT Processor time for the element.

SM2LPROU Processor user ID for the element.

SM2LPHRC Processor return code for the element.

SM2LPRC1 Endevor return code for the element.

SM2PRCLN Size of the action-specific block (header and detail) ifthe action-block detail uses the Processor InformationDSECT ($SM2LPRDS).



9.2.4.4 Request Parameter Info Action-Block Detail Field Descriptions(SM2REQDS)

The following table describes the Request Parameter Info action-block detailfields:

Field Description

SM2RCCID CCID associated with the current action request.

SM2RCOMM Comments associated with the current action request.

SM2RFLAG Not used.

SM2RSISO Indicates whether the current action requested asignout override: Y or N �1�

SM2RSICO Applicable for a RETRIEVE action. Indicates whetherthe current action specified copy-only: Y or N �1�

SM2REXPN Applicable for a RETRIEVE action. Indicates whetherthe current action requested that INCLUDEs beexpanded: Y or N �1�

SM2ROVER Applicable for a RETRIEVE action. Indicates whetherthe current action requested an overwrite if amember by the same name exists already in theoutput library: Y or N �1�

SM2RRTCD Not used.

SM2RDEL Indicates whether the element was deleted uponcompletion of the requested action: Y or N �1�. Thisvalue is X'40' if a delete does not apply for thecurrent action.

SM2REQLN Size of the action-specific block (header and detail) ifthe action-block detail uses the Request ParameterInformation DSECT ($SM2REQDS).

Note:

�1�:Y — Yes; N — No


Chapter 10. Global Type Sequencing

A type processing sequence is used when multiple element types are processedwithin a single batch request. When Global Type Sequencing is enabled,element actions are processed by type sequence regardless of the inventorylocation of each action. SCL and API element actions are executed in typesequence order defined at the site level in the Type Sequence member createdby the administrator.

By default, CA Endevor allows you to define the relative sequence ofprocessing for the various element types defined within a system. If your sitedoes not choose the Global Type Sequencing option, element actions executewithin your system in the same order as the types were defined to the systemand stage by the administrator or as reordered by the administrator using theType Sequence panel.

When Global Type Sequencing is in effect, any types that are not included inthe Type Sequence member are processed after all the types in the TypeSequence member have completed processing.Then they are processed in typename order.

The system MCF type sequence record is automatically maintained. However,the administrator cannot re-order the sequence, in foreground using the TypeSequence panel, if Global Type Processing is on. When new types are defined,they are simply added to the end of the list. If a new type is defined after theType Sequence member has been created and the type's processing sequence isimportant, edit the Type Sequence file to include the type in its properprocessing order.

If the Alternate ID features is active, CA Endevor uses the Alternate ID whenaccessing the PARMLIB file. This way the administrator can secure the file tothe Alternate ID.

Under Batch Admin, system level type sequencing is allowed; however, awarning message is generated when Global Type Sequencing is in effect atyour site.

Chapter 10. Global Type Sequencing 10-1

To implement Global Type Sequencing, the CA Endevor administrator must dothe following:

■ Allocate the Parmlib data set

■ Create a Type Sequence member file

■ Define the Parmlib data set and the Type Sequence member to the SiteOptions Table C1DEFLTS


10.1 Allocate the Parmlib Data Set

10.1 Allocate the Parmlib Data Set

The Parmlib data set contains the Type Sequence member. To allocate theParmlib data set, edit the BC1JEPRM member in your site's CA EndevorJCLLIB data set, and then execute the batch job.


10.2 Create Your Site's Type Sequence Member


The order of the type records in the Type Sequence member represents theprocessing sequence. You create and edit this file and then copy it to yoursite's Type Sequence member within CA Endevor's Parmlib data set. Typesnot defined in the member are processed in type name order after all typesdefined in the Type Sequence file are processed. The Type Sequence memberis composed of 80 byte records. You can use the standard ISPF editor to createthe file. A utility is provided to assist you in building the file.



10.2.1 Syntax Rules for Type RecordsThe type record syntax follows:

TYPE 'type name' [SYSTEM 'system name'] DESC 'Sample Type Description' .

The syntax rules are:

■ The system clause is optional. This clause allows multiple same namedtypes to be associated to different systems when different type sequenceorders are needed. If this clause is omitted, the type sequence order forthat type name will apply to the entire site.

■ The type name may be contained in single quotes, but this is notnecessary.

■ The type name cannot be greater than 8 characters.

■ The type name will be converted to upper case characters.

■ The system syntax clause is optional.

■ When specified, the system name must be explicit and cannot be greaterthan 8 characters. The system name is converted to uppercase characters.

■ The description must be enclosed in single quotes.

■ The description text can be up to 50 characters. When the text containssingle quotes, these quotes will be converted to blanks.

■ The description text may be entered in either upper or lower casecharacters.

■ The ending period (.) delimiter is necessary.

■ Both the type name and description fields are required.

■ Both the type name and description fields do not need to be on the samelines.

■ Text must not appear in columns 73 to 80.

You can add comment records to the file by placing an asterisk in the firstcolumn position.



10.2.2 Sample Type Sequence FileThe following is a sample of a type processing sequence file whose membername is ETYPESEQ. In this example, elements with a type of PROCESS will beprocessed before elements with a type of SCLLANG and so on.

� �Col 1

(

��

� ETYPESEQ: Site Type Processing Sequence member in BST.ENDEVOR.PARMLIB

��

TYPE 'PROCESS' DESC 'INTERNAL PROCESSING'.

TYPE 'SCLLANG' DESC 'SCL Language Definition (NODE/KEYWORD/FIELD)'.

TYPE 'CHDR' DESC 'C HEADER FILES'.

TYPE 'ASMMAC' DESC 'MACROS AND DSECT PROCESSOR'.

TYPE 'ASMCHDR'

DESC 'PUNCH C HDR AND ASM COPY MBR OF A DATA STRUCTURE'.

TYPE 'ASMPGM' DESC 'ASSEMBLER PROGRAM PROCESSOR'.

TYPE 'CPGM' DESC 'C PROGRAMS'.

TYPE 'LNK' DESC 'LINKEDIT PROCESSOR'.

� �

10.2.3 Build Utility for the Type Sequence MemberThe build utility is JCL member BC1JBTSE available in the site's CA EndevorCM JCLLIB data set. This utility builds type sequence records for all typesdefined to a site. Edit this member to conform to the needs of you installationbefore executing this job. The JCL builds a type sequence file to a sequentialwork file. You will probably need to edit this file by rearranging the typeorder or delete types from the file.

The utility extracts all MCF types defined in the site's C1DEFLTS table and aseach unique type name is encountered, a type sequence record is created.

The utility does not merge one system's type sequence with another. Uniquetype records are written to the file as they are processed, starting with the firstsystem in the first defined C1DEFLTS' environment/stage. The type sequencerecord's description field contains the description from the first unique typerecord.

The utility produces comment records to identify each type locationoccurrence. For example, if type MAC is defined in environment DEV (stage 1,2) under system BASE and in environment QA (stage 1,2) also under BASE,four comment records appear following the type sequence record:

� �TYPE 'MAC ' DESC 'MACROS AND DSECT PROCESSOR'

� ENV: DEV SYSTEM: BASE STG: 1

� ENV: DEV SYSTEM: BASE STG: 2

� ENV: QA SYSTEM: BASE STG: 1

� ENV: QA SYSTEM: BASE STG: 2

� �



The description field in the sequence record is set to the type's descriptionvalue. In this case, the description value is taken from location: environmentDEV, system BASE, stage 1. The stage values in the comment records are setto the stage number, not the ID value.

Considerations for Using the Utility: Most sites have favored environmentswhere their types follow the site's administration policies. For example, yoursite could have environment D40 and I40, which have many test systemswhere many elements in these locations have never been promoted up. If yoursite also had Q40 and P40 environments that represent true productioninventory, it would be best to run the utility against environments Q40 andP40 only.

To accomplish this, you can create a temporary C1DEFLTS table where theD40 and I40 environments are removed. Then this table could be used for justthis utility execution run. Doing this could limit the number of generated typestatements, which could help you define the initial type sequence order. Anyvalid types from environment D40 and I40 could then be added manually.


10.3 Define the Type Processing Member

10.3 Define the Type Processing Member

The Parmlib data set contains the Type Sequence member. Both the Parmlibdata set and the Type Sequence member must be defined to the Site OptionsTable, C1DEFLTS. The C1DEFLTS table will not assemble correctly if the TypeSequence member is defined to C1DEFLTS, but the Parmlib is not defined. Anempty Type Sequence member will force type sequencing by type name order.

To define the Parmlib data set and the Type Sequence file to CA Endevor, youmust add the PARMLIB= and TYPESEQMBR= parameters to C1DEFLTS andthen assemble and link-edit it to your authorized library as memberC1DEFLTS. For details, see the CA Endevor Optional Features TableENCOPTBL in the chapter "Optional Features."


Chapter 11. The User Options Menu Facility

This chapter describes the User Options Menu facility.

Chapter 11. The User Options Menu Facility 11-1

11.1 Menu Functions

11.1 Menu Functions

The User Options Menu facility allows the CA Endevor administrator to attachuser-defined functions to the CA Endevor ISPF front end. These functionsappear on the User Options Menu. The following options are available:

■ Option 1 — Build and submit Endevor batch report requests

■ Option 2 — Invoke the ACM Query Facility

� �------------------------- Endevor User Options Menu -----------------------

Option ===>

1 REPORTS - Build Endevor Report Requests

2 ACMQ - Endevor ACM Query Facility

Enter END to return to the Endevor Primary Options Menu

� �

The User Options Menu is delivered as member NDVRUSER in theiprfx.iqual.ISPPLIB library. The CLISTs, panels, messages, and skeleton JCL forthe REPORTS option on this menu are delivered in the following libraries:

■ CLISTs are stored in the iprfx.iqual.ISRCLIB library as members C1SR1000;C1SR1100; C1SR1200; C1SR1300; C1SR1400; and C1SR1500.

■ Panels are stored in the iprfx.iqual.ISPPLIB library as members C1SR1000;C1SR1100; C1SR1200; C1SR1300; C1SR1400; and C1SR1500.

■ Messages are stored in the iprfx.iqual.ISPMLIB library as member CISR00.

■ Skeleton JCL is stored in the iprfx.iqual.ISPSLIB library as membersC1SR8000 and C1SR8100.


11.2 User Option Menu Panel Overview


The User Option Menu panel is delivered with functionality to invoke a reportCLIST, the ACM Query CLIST. You may decide to modify this panel toremove selections not installed at your site or to add additional CA Endevorrelated selections for features you develop.

If you decide to customize the User Options Menu, we recommend you do sowithin CA Endevor. This ensures any changes you make are recorded aschange levels.

11.2.1 SourceThe source for the User Options Menu, as delivered and installed with CAEndevor, is shown next:

)ATTR

/�----------------------------------------------------------------�/

/� �/

/� �/

/� NAME: NDVRUSER �/

/� �/

/� Note: If you remove/add entries to/from this panel, be �/

/� sure to modify the CMD line(s) in the )PROC area �/

/� in addition to the descriptive text line(s) in �/

/� )BODY area. �/

/�----------------------------------------------------------------�/

/� Attribute Characters: �/

+ TYPE(TEXT) INTENS(LOW)

% TYPE(TEXT) INTENS(HIGH)

@ TYPE(TEXT) INTENS(LOW)

# TYPE(TEXT) INTENS(LOW)

)BODY

%--------------------------- Endevor User Options Menu -------------

% Option ===>_ZCMD

%

% 1+ REPORTS - Build Endevor reporting requests

%

% 2+ ACMQ - Endevor ACM Query Facility

%

%

%

%

%

%

%

%

%

%

%

%



%

%

%

%

% Enter%END+to return to the Endevor Primary Options Menu

%

)INIT

.HELP = BCSTUSER

&CTLNBR = ''

&DESCRPT1 = ''

)PROC

/�-----------------------------------------------------------------�/

/� The following ZSEL statement will invoke the command or panel �/

/� associated with each option identified above. �/

/�-----------------------------------------------------------------�/

&ZSEL = TRANS( TRUNC (&ZCMD,'.')

1,'CMD(%C1SR1�� DEBUG(NOBUG))'

/� The following option supports ACM �/

2,'CMD(%ACMQ DEBUG(NOBUG))'

)END

11.2.2 Modifying the User Options MenuTo add options on this panel, perform the following steps:

1. Add an option character and descriptive text to the )BODY section of thepanel. It is recommended that you copy one of the existing lines as astarting point. This way the attributes (% , +) are consistent. For example:

% U+NDVRUTL - Endevor Client Utility

2. Add a new line to the selection statement (ZSEL) in the )PROC section ofthe panel source. For example:

U,'CMD(%NDVRUTL DEBUG(NOBUG))'

To remove options on this panel, perform the following steps:

1. Remove the option character and descriptive text from the )BODY sectionof the panel. This can be accomplished by typing over the charactersusing the space bar, using the EOF key or deleting the entire line.

2. Remove the associated line from the selection statement (ZSEL) in the)PROC section of the panel source. This can be accomplished by deletingthe entire line or by making it into a comment by placing the /* beforeand after the parameters. For example:

/� 3,'CMD(%ENNMENU DEBUG(NOBUG))' /�



ISPF panels support a maximum of 24 display lines. The delivered panelcontains 24 lines. Line 23 contains the text "Enter END to return" and the 24thline is left blank to support split screen mode. It is strongly recommended thatyou do not alter the number of lines in the )BODY section. If the panelcontains more than 24 lines, ISPF issues an error message when attempting todisplay the panel. If it contains less than 24 lines, ISPF adds blank lines to theend of the panel. Avoid these errors by:

■ Replacing a deleted line with a blank line. The line must contain the %attribute character in column 1.

■ Deleting a blank line when adding a new line.


Chapter 12. The ISPF Dialog Options ConfigurationTable

This chapter explains how you can customize the Endevor ISPF dialog optionsconfiguration table for your site.

Chapter 12. The ISPF Dialog Options Configuration Table 12-1

12.1 Configuring ISPF Dialog Options

12.1 Configuring ISPF Dialog Options

The dialog options configuration table feature allows you to override defaultvalues set for specific options associated with Endevor actions. The defaults areassigned in an ISPF dialog configuration table that is shipped with theEndevor installation files. You can override the assigned default values byupdating and assembling the ISPF configuration table, ENDICNFG.

If you do not want to change the dialog default field values, you do not needto take any action. Endevor uses the configuration table that is shipped withthe installation tape.

Important! This feature allows you to establish the default values that appearautomatically on the foreground action panels. During an Endevor session, however, auser can still change the value for one or more options on an individual panel(s).

12.1.1 What You Can ChangeYou can set default values for all Y/N action option fields and for most listfields. You can also set the default package selection fields. For a list of thedialog fields that can be updated, see the table in Dialog Options Fields in thischapter.

12.1.2 What You Cannot ChangeYou cannot set default values for the CCID, COMMENT, PROCESSOR GROUPfields, the list option WHERE fields, or data set name fields.


12.2 The Default Configuration Table


The Endevor files contain the default configuration table, ENDICNFG, and theJCL you can use to reassemble and link-edit the table. This table contains theexisting default values.

To change the default of any dialog field, proceed as follows:

1. Edit the parameters you want to change.

2. Reassemble and link-edit the configuration table.

The parameters are discussed in the section, Dialog Options Fields in thischapter. The JCL you use to reassemble and link-edit the table is shown in thesection, Dialog Options Fields in this chapter. The table shown next is thedefault configuration table provided with the Endevor installation files as amember in the installation SOURCE library.

Note: The default configuration table is regularly updated until the time ofshipping. For the most recent version of ENDICNFG, see the memberENDICNFG in iprfx.iqual.SOURCE.

TITLE 'ENDICNFG - ENDEVOR/MVS ISPF DIALOG CONFIGURATION TABLE'

�---------------------------------------------------------------------�

� �

� �

� NAME: ENDICNFG �

� �

� PURPOSE: THIS IS THE ENDEVOR/MVS ISPF DIALOG CONFIGURATION TABLE. �

� THE CONFIGURATION TABLE DEFINES THE INSTALLATION DEFAULTS FOR �

� CERTAIN DIALOG PANEL FIELDS. THE INSTALLATION CAN CUSTOMIZE THIS �

� TABLE TO PROVIDE A LIMITED AMOUNT OF FLEXIBILITY IN SETTING THE �

� VALUES THAT THE DIALOG WILL USE TO INITIALIZE PANEL FIELDS. �

� �

� ATTRIBUTES: REENTRANT, REUSABLE �

� NON-EXECUTABLE �

� AMODE(31), RMODE(ANY) �

� �

�---------------------------------------------------------------------�

END$CNFG TYPE=CONFIG, X

ACKNOWLEDGE_ELEMENT_JUMP=N, X

APPEND_SCL=N, X

APPEND_SCL_PKG=N, X

APPROVED=Y, X

BROWSE_VIEW_MODE=B, X

BUILD_USING_MAP=Y, X

COMMITTED=Y, X

COMPONENT_LIST_WORD=LIST, X

COMPONENTS_ONLY=N, X

COPYBACK=N, X

DELETE_AFTER_ARCHIVE=N, X

DELETE_AFTER_MOVE=Y, X



DELETE_AFTER_TRANSFER=Y, X

DELETE_INPUT_SOURCE=N, X

DELETE_MODE=F, X

DENIED=Y, X

DISPLAY_PROC_GROUP=N, X

ENABLE_BACKOUT=Y, X

ENTERPRISE_PKG=A X

EXECUTED=Y, X

EXPAND_INCLUDES=N, X

GENERATE_ELEMENT=Y, X

GENERATE_MODE=F, X

IN_APPROVAL=Y, X

IN_EDIT=Y, X

IN_EXECUTION=Y, X

INCLUDE_JCL=N, X

INCREMENT_JOBNAME=Y, X

INTERCEPT_ISPF_RETURN=N, X

JCL_PROCEDURE_NAME=ENDEVOR, X

MOVE_MODE=F, X

MULTIPLE_JOBSTREAMS=N, X

OVERRIDE_SIGNOUT=N, X

PROCESSOR_GROUP_DEFAULT_CHAR=-, X

PROCESSOR_GROUP_OVERRIDE_CHAR=O, X

QE_BUILD_USING_MAP=Y, X

QE_GENERATE_IN_PLACE=N, X

QE_RETURN_FIRST_FOUND=Y X

REPLACE_MEMBER=N, X

RETAIN_SIGNOUT=N, X

RETURN_FIRST_FOUND=Y, X

SHARABLE_PACKAGE=N, X

SHOW_TEXT=Y, X

SIGNIN_MODE=F, X

SIGNOUT_ELEMENT=Y, X

SIGNOUT_MODE=F, X

SORT_BY_DESTINATION_ID=2, X

SORT_BY_PACKAGE_ID=3, X

SORT_BY_SHIP_DATE=1, X

SYNCHRONIZE=N, X

UPDATE_IF_PRESENT=N, X

VALIDATE_COMPONENTS=Y, X

WITH_HISTORY=N,

WORKLIST_PRIMARY=1

WORKLIST_SECONDARY=1

END


12.3 Dialog Options Fields


Each option is a dialog field in the configuration table. There are two kinds offields: those that affect how Endevor processes the action and those that affectthe information returned or presented by Endevor.

The following table lists each of the Endevor dialog fields for which your sitecan override the default value. The first column contains the field names asthey appear in the configuration table. These names map to the action optionor list option names that appear on the element or package action panels. Thelast column in the table indicates whether this is an action option (A), a list orfilter option (F), or an option that influences Endevor's behavior (O).

ISPF DialogField Name

ValidValues

CurrentDefault

Panel FieldDescription

Action,Filter, orOther

ACKNOWLEDGE_ELEMENT_JUMP

Y or N N Acknowledgeelement jump.

A

APPEND_SCL Y or N N Default value forthe “APPEND”field on the BatchOptions panel.

F

APPEND_SCL_PKG

Y or N N Default value forthe “APPEND TOPACKAGE” fieldon theCreate/ModifyPackage panel.

F

APPROVED Y or N Y IncludeAPPROVEDpackages.

F

BROWSE_VIEW_MODE

B or V B Default displaymode; B forbrowse, V orview.

O

BUILD_USING_MAP

Y or N Y Build the elementselection list usingthe EnvironmentMap.

F

COMMITTED Y or N Y IncludeCOMMITTEDpackages.

F




ValidValues

CurrentDefault



COMPONENT_LIST_WORD

User-defined LIST Text string used toidentify the listingdata set namewhen the LLoption is selectedin Quick-Edit.

F

COMPONENTS_ONLY

Y or N N Delete only theelementComponent List.

A

COPYBACK Y or N N Copy an elementfrom up the mapduring generateprocessing.

A

DELETE_AFTER_ARCHIVE

Y or N N Delete the elementor package afterthe ARCHIVEaction completes.

A

DELETE_AFTER_ MOVE

Y or N Y Delete the sourceelement after theMOVE actioncompletes.

A

DELETE_AFTER_TRANSFER

Y or N Y Delete the sourceelement after aTRANSFER actioncompletes.

A

DELETE_INPUT_SOURCE

Y or N N Delete the inputsource after anADD actioncompletes.

A

DELETE_ MODE F or B F Default modewhen executingthe delete actionin Quick-Edit; Ffor foreground, Bfor batch.

A

DENIED Y or N Y Include deniedpackages.

F




ValidValues

CurrentDefault



DISPLAY_PROC_GROUP

Y or N N Default value forthe “DISPLAYPROC GRPNAME” field onthe DisplayElements/ComponentLists panel.

F

ENABLE_BACKOUT

Y or N Y Enable packagebackout.

A

ENTERPRISE_PKG

A or E orX

A ISPF PackageSelection list filteroption. If A, listsenterprise andnon-enterprisepackages. If E,lists enterprisepackages only.IfX, listsnon-enterprisepackages only.

F

EXECUTED Y or N Y Include executedpackages

F

EXPAND_INCLUDES

Y or N N Expand imbeddedINCLUDESduring aRETRIEVE action.

A

GENERATE_ELEMENT

Y or N Y Generate anelement as part ofquick-edit ortransferprocessing.

A

GENERATE_MODE

F or B F Generate theelement inForeground (F) orBatch (B) inQuick-Edit.

F

IN_APPROVAL Y or N Y Include packagesthat are in theapproval process.

F




ValidValues

CurrentDefault



IN_EDIT Y or N Y Include packagesthat have not yetbeen cast.

F

IN_EXECUTION Y or N Y Include packagesthat are executing.

F

INCLUDE_JCL Y or N N Default value forthe “INCLUDEJCL” field on theBatch Optionspanel.

F

INCREMENT_JOBNAME

Y or N Y Indicates whetherthe Batch PackageFacility incrementsthe last characterin the jobcard youprovide when yousubmit a packagejobstream.

O

INTERCEPT_ISPF_RETURN

Y or N N Instruct Endevorwhether tointercept ISPFRETURN andJUMP commands.

O

JCL_PROCEDURE_NAME

1-8alphanumericcharacters

Endevor The name of theEndevorprocedure that theSUBMITPACKAGE actionwill use to createJCL. A sampleprocedure can befound iniprfx.iqual.JCLLIB, membername PACKAGE.Use this as amodel for yourown Submitprocedure.

A




ValidValues

CurrentDefault



MOVE_MODE F or B F Default modewhen executingthe move action inQuick-Edit; F forforeground, B forBatch.

A

MULTIPLE_JOBSTREAMS

Y or N Y Indicates whethermultiple packagesare submitted asseparate jobs (Y)or as job stepswithin a singlejobstream (N),when using theBatch PackageFacility(ENBP1000).

A

OVERRIDE_SIGNOUT

Y or N N Override theelement signoutstatus.

A

PROCESSOR_GROUP_DEFAULT_CHAR

-- Specify thecharacter to beused to indicatethat the processorgroup symbol isusing the defaultfrom the PROCstatement of theprocessor.

O

PROCESSOR_GROUP_OVERRIDE_CHAR

O Specify thecharacter to beused to indicatethat the processorsymbol has beenoverridden by theprocessor groupsymbol.

O




ValidValues

CurrentDefault



QE_BUILD_USING_MAP

Y or N Y Quick-Edit ISPFdisplay option. Ifset to N, displayincludes elementsin Stage 1 andStage 2. If set to Y,display includeselements from allstages andenvironment inthe map.

QE_GENERATE_IN_PLACE

Y or N N Quick-Edit ISPFpanel actionoption. If Y,element will begenerated in thestage where it isfound. If N,element will becopied back intothe entry stage.

QE_RETURN_FIRST_FOUND

Y or N Y If Y, returns onlythe first occurenceof the requestedelement(s). If N,returns alloccurrences of therequestedelement(s) foundalong the maproute.

REPLACE_MEMBER

Y or N N Replace anexisting memberin a partitioneddata set.

A

RETAIN_SIGNOUT

Y or N N Retain the signoutduring move ortransferprocessing.

A




ValidValues

CurrentDefault



RETURN_FIRST_FOUND

Y or N Y Include only thefirst occurrence ofthe element foundin theenvironment map.

F

SHARABLE_PACKAGE

Y or N N Identify whether apackage issharable.

A

SHOW_TEXT Y or N Y Show text duringlist actionprocessing.

A

SIGNIN_ MODE F or B F Default modewhen executingthe signin actionin Quick-Edit; Ffor foreground, Bfor batch.

A

SIGNOUT_ELEMENT

Y or N Y Signout anelement duringRETRIEVEprocessing.

A

SIGNOUT_MODE

F or B F Default modewhen executingthe signout actionin Quick-Edit; Ffor foreground, Bfor batch.

A

SORT_BY_DESTINATION_ID

1 or 2 or 3 2 Sort the packageshipment list bydestination ID.

F

SORT_BY_PACKAGE_ID

1 or 2 or 3 3 Sort the packageshipment list bypackage ID.

F

SORT_BY_SHIP_DATE

1 or 2 or 3 1 Sort the packageshipment list byshipment date.

F




ValidValues

CurrentDefault



SYNCHRONIZE Y or N N Create asynchronizationlevel as part ofmove or transferprocessing.

A

UPDATE_IF_PRESENT

Y or N N Update anelement on anADD action if theelement alreadyexists at the entrystage.

A

VALIDATE_COMPONENTS

Y or N orW

See theNote atthe endof thistable

Validate thecomponents of apackage as part ofcast processing.

A

WITH_HISTORY Y or N N Maintain theelement changehistory.

A

WORKLIST_PRIMARY

1 to 999 1 Set the primarydefaults for theWORK DATASETALLOCATIONand the LISTDATASETALLOCATION.

O

WORKLIST_SECONDARY

1 to 999 1 Set the secondarydefaults for theWORK DATASETALLOCATIONand the LISTDATASETALLOCATION.

O

Note: For VALIDATE_COMPONENTS the default value depends on thevalue of the PKGCVAL= parameter in the Endevor Defaults Table.



JCL (BC1JCNFG): The JCL shown next can be used to assemble and link-editthe ISPF configuration table. This JCL is provided on the Endevor installationfiles, as member BC1JCNFG in the installation JCL library.//�(JOBCARD)

//�-------------------------------------------------------------------�

//� �

//� �

//� NAME: BC1JCNFG �

//� �

//� PURPOSE: THIS JCL IS USED TO ASSEMBLE AND LINK EDIT THE �

//� ENDEVOR/MVS ISPF CONFIGURATION TABLE. �

//� �

//� TO EXECUTE THIS JCL: �

//� 1) ADD THE APPROPRIATE JOB CARD �

//� 2) MODIFY THE //SYSLIB AND //SYSIN DD STATEMENTS IN THE ASM �

//� STEP TO REFER TO THE ENDEVOR INSTALLATION DATA SETS. �

//� 3) MODIFY THE //SYSLMOD DD STATEMENT IN THE LINK STEP TO REFER �

//� TO THE INSTALLATION AUTHLIB DATA SET �

//� �

//�-------------------------------------------------------------------�

//ASM EXEC PGM=ASMA9�,

// REGION=4�96K,

// PARM=('NOTERM,NODECK,LIST,OBJECT,XREF(SHORT)')





//SYSLIN DD DSN=&&OBJECT,

// UNIT=tdisk,

// SPACE=(TRK,(1,5)),


// DCB=(LRECL=8�,RECFM=FB,BLKSIZE=32��)

//SYSLIB DD DISP=SHR,DSN=iprfx.iqual.SOURCE

//SYSIN DD DISP=SHR,DSN=iprfx.iqual.SOURCE(ENDICNFG)


// REGION=2�48K,

// PARM='LIST,MAP,XREF,RENT,REUS'


//SYSLIN DD DSN=&&OBJECT,

// DISP=(OLD,DELETE,DELETE)

//SYSUT1 DD DSN=&&SYSUT1,

// UNIT=tdisk,

// SPACE=(TRK,(2,5)),

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

// DCB=BLKSIZE=1�24

//SYSLMOD DD DISP=SHR,DSN=iprfx.iqual.AUTHLIB(ENDICNFG)


Chapter 13. The Defaults Table

This chapter provides detailed information about the Endevor Defaults Table(C1DEFLTS), and explains how to update it. The sections are:

■ About the Defaults Table

■ The C1DEFLTS Macro

■ Editing the Defaults Table

■ Assembling the Defaults Table

■ The TYPE=MAIN Macro

■ The TYPE=ENVRNMNT Macro

■ The TYPE=END Macro

Chapter 13. The Defaults Table 13-1

13.1 About the Defaults Table

13.1 About the Defaults Table

The Endevor Defaults Table contains your global system information, such asEndevor options installed at your site, Endevor control data set names, andsettings available for Endevor features. Although all of these parameters areset at system installation, you may need to change the Defaults Table if yoursite purchases a new Endevor product, your library names change, or youwant to tailor the information entered by the system installer. The tablecomprises a set of "C1DEFLTS" macros which, when assembled andlink-edited, are known collectively as the Defaults Table.

The Defaults Table should reside in an authorized data set.


13.2 The C1DEFLTS Macro

13.2 The C1DEFLTS Macro

There are three occurrences of the C1DEFLTS macro:

■ TYPE=MAIN macro defines site-specific information. It must be the firstmacro specified in the table source. Only one TYPE=MAIN macro can bespecified.

■ TYPE=ENVRNMNT macro defines environment information. You can haveany number of these macros in the table, but you must have one macro foreach environment in your configuration. The TYPE=ENVRNMNT macrosfollow the TYPE=MAIN macro.

■ TYPE=END indicates the end of the table definition. It follows the lastTYPE=ENVRNMNT macro.


13.3 Editing the Defaults Table

13.3 Editing the Defaults Table

When you edit the C1DEFLTS macro, follow the following standard IBM rules:

■ Place all macro specifications between columns 2 and 71.

■ To continue across lines, place an X in position 72 and start thecontinuation card at position 16 of the next line. Leave at least one blankspace between the end of one card (usually a comma) and the continuationcharacter in position 72.

■ Include at least one space between the macro name—C1DEFLTS—and thefirst keyword parameter—TYPE.

■ Within each parameter specification, do not include any spaces. If you areusing literal operands that include a space, enclose the operand in singlequotes.

Warning: When editing the macros, pay special attention to the comma andcontinuation character (X) that follow all but the last parameter within eachmacro. If either of these are inadvertently deleted, the table assembles with areturn code of zero, but problems will result at Endevor execution.


13.4 Assembling the Defaults Table


When you have edited the Defaults Table, you need to assemble and link-editthe table. Use BC1JDEFT JCL, shown next, to do this. Store the load module inyour authorized library as member C1DEFLTS.

If you have not already done so, copy your JOBCARD member to thebeginning of BC1JDEFT. Be sure the edited macros are placed correctly in thejob stream, then submit the job for execution.

//�(JOBCARD)

//�-------------------------------------------------------------------�

//� �

//� �

//� NAME: BC1JDEFT �

//� �

//� PURPOSE: BC1JDEFT IS USED TO ASSEMBLE AND LINK EDIT THE �

//� ENDEVOR DEFAULTS TABLE. BY DEFAULT, THE TABLE IS NAMED �

//� C1DEFLTS. THE INSTALLATION CAN OVERRIDE THE DEFAULT TABLE �

//� NAME BY WRITING A CUSTOMIZED VERSION OF THE ENXUSITE USER EXIT �

//� �

//�-------------------------------------------------------------------�

//�-------------------------------------------------------------------�

//� �

//� STEP 1: ASSEMBLE THE ENDEVOR DEFAULTS TABLE �

//� �

//�-------------------------------------------------------------------�


// REGION=3�72K,

// PARM='NODECK,OBJECT,NOTERM,LIST,XREF(SHORT)'



// UNIT=tdisk,

// SPACE=(TRK,(3,5)),


// DCB=(RECFM=FB,LRECL=8�,BLKSIZE=32��)

//SYSPUNCH DD DUMMY



//SYSIN DD �

.

.

C1DEFLTS MACROS GO HERE

.

.

/�

//�-------------------------------------------------------------------�

//� �

//� STEP 2: LINK EDIT THE DEFAULTS TABLE. �

//� �

//� THE SYSLMOD DD STATEMENT DEFINES THE LOCATION AND THE NAME OF THE�

//� DEFAULTS TABLE. THE DEFAULT TABLE NAME IS C1DEFLTS. IF YOU ARE �



//� USING A ENUXSITE USER EXIT, YOU CAN CHANGE THE TABLE NAME AS �

//� APPROPRIATE. �

//� �

//� THE LOAD MODULE CREATED BY THIS STEP IS PLACED INTO THE USER �

//� DEFINED AUTHLIB DATA SET. THE ENDEVOR DEFAULTS TABLE MUST �

//� RESIDE IN AN AUTHORIZED LIBRARY. �

//� �

//�-------------------------------------------------------------------�


// REGION=2�48K,

// PARM='LIST,NCAL,XREF,LET,RENT,REUS',

// COND=(�,NE)




//SYSLMOD DD DISP=SHR,DSN=uprfx.uqual.AUTHLIB(C1DEFLTS)


The job steps in job BC1JDEFT do the following:

Step Action

1 Assembles macros and passes the assembled Defaults Tableto Step 2.

2 Link-edits the Defaults Table and stores it in the loadmodule into uprfx.uqual.AUTHLIB as member C1DEFLTS.


13.5 The TYPE=MAIN Macro


The TYPE=MAIN macro defines site-specific information. It must be the firstmacro specified in the table source. Only one TYPE=MAIN macro can bespecified.

The TYPE=MAIN macro is shown next:


ACCSTBL=, ACCESS SECURITY TABLE NAME X

ACMROOT=, ACM INDEX ROOT DATA SET NAME X

ACMXREF=, ACM INDEX XREF DATA SET NAME X

APRVFLG=N, APPROVAL PROCESSING (Y/N) X

ASCM=N, ACM CONTROL OPTION X

AUTHTBLS=REQUIRED, REQUIRED|ALLOW|IGNORE X

BATCHID=�, BATCH UID FROM JOBNAME/USER= X

CA7CCINODE=, CA-7 ADDR SPACE NODE (CAICCI) X

CA7JCLID=, CA-7 JCL DATASET INDEX NUMBER X

CA7JCLLIB=, CA-7 JCL DATASET SYMBOIC INDEX X

CA7JCLDSN=, CA7JCLID/CA7JCLLIB DSNAME X

CIPODSN=, CCID VALIDATION DATASET NAME X

CNFGTBL=ENDICNFG, CONFIGURATION TABLE NAME X

CUNAME='�� PUT YOUR COMPANY NAME HERE ��', (5� CHAR) X

DB2=N, DB2 CONTROL OPTION X

EDITELM=N, EDIT ELEMENT DIALOG OPTION X

ELMCATL='UPRFX.UQUAL.ELMCATL', E/MVS CATALOG X

ELMCATE='UPRFX.UQUAL.ELMCATE', E/MVS CATALOG EINDEX X

ESMTPTBL=ESMTPTBL, ENDEVOR SMTP TABLE NAME X

ESSI=N, ESI CONTROL OPTION X

EXITTBL=C1UEXITS, EXIT TABLE NAME X

INFO=N, INFO/MAN CONTROL OPTION X

JRNLGRP=, PITR JOURNAL GROUP ID X

LIBENV=, LIBRARIAN (LB), PANVALET (PV) X

LIBENVP=N, LIBRARIAN/PANVALET OPTION X

LIBRPGM=, LIBRARIAN BATCH PROGRAM NAME X

LINESPP=6�, LINES PER PAGE X

MACDSN='IPRFX.IQUAL.SOURCE', E/MVS SOURCE LIBRARY X

MIXEDFMT=, ALL|(CCID,COMMENT,DESCRIPTION) X

MODHLI=, HLQ FOR TEMPORARY DATA SETS ) X

NMAN=N, CA-NETMAN INTERFACE OPTION X

OPTTBL=ENCOPTBL, OPTIONS TABLE NAME X

PARMLIB=, ENDEVOR PARMLIB DATA SET NAME X

PDM=N, PDM CONTROL OPTION X

PKGDSN='UPRFX.PACKAGE.MASTER', PACKAGE DATASET X

PKGTSO=N, FOREGROUND PACKAGE EXEC (Y/N) X

PKGCSEC=N, PACKAGE CAST SECURITY (Y/N) X

PKGCVAL=O, PKG COMPONENT VALIDATION Y/N/O X

PKGSEC=APPROVER, APPROVER/ESI/MIGRATE X

PRBLKSZ=�, BLKSZE PROC LISTING X

PRLNKSZ=(896K,96K), LINKAGE SIZE FOR PROCS X

PRLSTSZ=1�, SIZE ALLOC FOR PROCS LISTINGS X

PROC=N, PROCESSOR OPTION X



RACFGRP=, ALTERNATE ID RACF GROUP X

RACFPWD=, ALTERNATE ID PASSWORD X

RACFUID=, ALTERNATE ID USERID X

RJCLROOT=, SHIP REMOTE JCL MODEL MBR ROOT X

SITEID=�, ENDEVOR/MVS SITE IDENTIFIER X

SYMBOLTBL=, SITE-DEFINED SYMBOL TBL NAME X

SMFREC#=�, SMF RECORD NUMBER X

SOFETCH=N, SIGNOUT UPON FETCH (Y/N) X

SPFEDIT=SPFEDIT, DEFAULT PDS RESERVE X

SYSIEWL=SYSIEWLP, DEFAULT PDS/LINK EDIT RESERVE X

TYPESEQMBR=, ENDEVOR TYPE SEQ MBR X

UIDLOC=(1,7), UID/JOBNAME START/LENGTH POS X

VIOUNIT=TDISK, UNIT FOR VIO-ELIGIBLE ALLOC X

WRKUNIT=TDISK, UNIT NAME FOR WORK SPACE X

WORKVOL= VOL SER NUMBER FOR WRKUNIT

Each TYPE=MAIN parameter is defined in the following table:


ACCSTBL The 1- to 8-character name of the Endevor AccessSecurity Table used at your site. You must enter avalid name.

If you are using native security and leave the fieldblank, no security checking will be done.

If you are using the Endevor ESI feature and leavethis field blank, the Access Security Table namedefaults to BC1TNEQU.

ACMROOT The data set name of the VSAM file your site willuse to store the name of each Endevor element andall its related components. The recommended nameis uprfx.uqual.ACMROOT.

This data set is required if your site plans to use theACM Query Facility.

For more information, see the AutomatedConfiguration Option Guide.

ACMXREF The data set name of the VSAM file you will use tostore the name of each component relationship. Therecommended name is uprfx.uqual.ACMXREF.

The data set is required if your site plans to use theACM Query Facility.





APRVFLG Indicates whether approval processing is required.Set this parameter to Y if approval processing isrequired.

If you set this parameter to N, approval processingwill not be active no matter what approver grouprelationships have been defined.

ASCM Indicates whether the Endevor AutomatedConfiguration Manager (ACM) facility is enabled atyour site. If your site is using ACM, specify Y.Otherwise, specify N.


AUTHTBLS Indicates whether Endevor's security tables must beloaded from authorized libraries. Values are:

■ REQUIRED—Authorized libraries are required.This is the default value.

■ ALLOW—Unauthorized libraries are allowed,but Endevor will issue a warning message.

■ IGNORE—Endevor does not check the libraries'authorization.

BATCHID (Requiredentry)

Indicates whether the Endevor user ID associatedwith a batch job should be determined by theJOBNAME or the USER parameter specified on thejobcard. Values are:

■ 0—determined by JOBNAME (this is the defaultvalue)

■ 1—determined by the USER parameter

■ 2—determined by the USER parameter ifspecified, otherwise by the JOBNAME

For more information, see Selecting a BATCHIDOption in this chapter.

CA7CCINODE Specifies the CAICCI node name where the CA-7address space executes. If no name is specified,local mode is assumed.

CA7JCLID Provides Endevor with the CA-7 parameterinformation required by CA-7 to schedule JOBexecution. Parameter values should be obtainedfrom the CA-7 implementation. Mutually exclusivewith CA7JCLLIB.




CA7JCLLIB Provides Endevor with the CA-7 parameterinformation required by CA-7 to schedule JOBexecution. Parameter values should be obtainedfrom the CA-7 implementation. Mutually exclusivewith CA7JCLID.

CA7JCLDSN The data set name associated with CA7JCLID orCA7JCLLIB.

CIPODSN The data set name of the sequential file your siteplans to use to store valid CCID values. Therecommended name is uprfx.uqual.VALCCID.

This data set is required if you want to use theCCID validation facility.

For more information, see the Administrator Guide.

CNFGTBL Specifies the name of the Endevor ConfigurationTable. By default, Endevor uses the name,ENDICNFG.

CUNAME (Requiredentry)

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

DB2 Indicates whether the Endevor for DB2 applicationis enabled at your site. If your site is using Endevorfor DB2, specify Y. Otherwise, enter N.

For more information, see the Endevor for DB2 Guide.

EDITELM Indicates whether the Endevor Quick Edit feature isenabled at your site. If your site is using thisfeature, specify Y. Otherwise, enter N.

For more information, see the Quick Edit Option UserGuide.

ELMCATL The 1-44 character data set name of the elementcatalog VSAM file. Endevor uses the ElementCatalog file to support long element names and toboost performance by reducing the volume of I/Ooperations.

ELMCATE The name of the element catalog EINDEX VSAMfile. If left blank, the name will default to the namespecified for ELMCATL with a suffix of .EINDEX. Ifyou are currently using an EINDEX and you leavethe ELMCATE field blank, the name defaults to thename you are currently using.

ESMTPTBL Specifies the name of the Endevor SMTP Table. Bydefault, Endevor uses the name, ESMTPTBL.




ESSI Indicates whether the Endevor ESI facility isenabled at your site. If your site is using EndevorESI, specify Y. Otherwise, enter N.

For more information, see the Security Guide.

Note: Do not activate this option until all of thesecurity rules are written and in place.

EXITTBL Specifies the name of the Endevor Exit Table. Bydefault, Endevor uses the name, C1UEXITS.

INFO Indicates whether the EndevorInformation/Management interface (Info/Man) isenabled at your site. If your site is using Info/Man,specify Y. Otherwise, enter N.

For more information, see the Interface for IBM TivoliInformation Management Administration Guide.

Note: Do not activate this option until theInformation/Management interface is fully installed.

JRNLGRP An L-Serv journal group ID which, when entered,relates the package data set named in this macro toa specific set of L-Serv journal files. Use of thisparameter enables journaling in the Package ControlFile.

The format is: (gggg,nnnn)

Values are:

■ gggg—The journal group ID associated with thepackage journal files.

■ nnnn—The journal group subsystem ID.

For more information, see the Utilities Guide.




LIBENV This parameter serves two purposes dependingupon the LIBENVP parameter.

■ If LIBENVP=Y,then

– LIBENV=PV indicates that Panvalet isinstalled;

– LIBENV=LB indicates that Librarian isinstalled.

■ If LIBENVP=N (default), then the includemember syntax is used by CONWRITE and/orthe Expand Include Utility as follows:

– LIBENV=PV tells Endevor to check forPanvalet include member syntax(++INCLUDE) or COBOL COPY statements,

– LIBENV=LB tells Endevor to check forLibrarian include member syntax (-inc) orCOBOL COPY statements

– LIBENV=blank (default), no syntax checkingor expanding will occur.

LIBENVP Indicates whether your site is using Librarian orPanvalet with Endevor. If your site is using one ofthese library management applications, specify Y.Otherwise, N.

LIBRPGM Applicable only if the LIBENV value is LB. This isthe name of the Librarian load module for your site.

LINESPP The number of lines per printed page for outputgenerated by Endevor. Default is 60. Valid entriesare 1-99.

MACDSN (Requiredentry)

The data set name of the library containing theEndevor macros. This library was created duringthe Endevor installation procedure. Therecommended name is iprfx.iqual.SOURCE.

The data set is used by many Endevor functionsand is required.




MIXEDFMT Determines whether Endevor accepts mixed-caseentries in CCID, COMMENT, and DESCRIPTIONfields. Values are:

■ CCID—Accept mixed case in CCID fields.

■ COMMENT—Accept mixed-case in COMMENTfields.

■ DESCRIPTION—Accept mixed-case inDESCRIPTION fields.

■ ALL—Accept mixed-case in all three fields.

■ NONE—Do not accept mixed-case in any field.

Multiple values can be specified by enclosing thevalues in () and separating them by a comma. Forexample, =(CCID,COMMENT).




MODHLI Allows you to assign a prefix other than SYSyydddto a temporary data set, creating apseudo-temporary data set. This applies to thosetemporary data sets which are allocated DISP=MODat any step in a processor only. Regular temporarydata sets, which are not DISP=MOD, use thestandard z/OS temporary data set name. This prefixappears as the first node of the data set name.

The value specified should be a high-level qualifier,which all Endevor users are authorized to use whenallocating, deleting, and opening files for output.

The effective name generated is:

modhli.Dyyddd.Thhmmss.RA0.jobname.ddname

Values are:

■ modhli—the data specified in the MODHLIoperand

■ yyddd—the Julian date

■ hhmmss—the time in hours, minutes, andseconds

■ jobname—the same value as jobname

■ ddname—the DDname specified in theprocessor JCL

RA0 is used instead of RA000 to make room for8-byte MODHLI and 8-byte DDnames.

If MODHLI is not specified in the Defaults Table,the effective name is:

SYSyyddd.Thhmmss.RA0.jobname.ddname

NMAN Indicates whether the Endevor Netman Interface isenabled at your site. If your site is using theNetman Interface, specify Y. Otherwise, enter N.

For more information, see the Interface forCA-Netman Administration Guide.

OPTTBL Specifies the name of the Endevor Options Table. Bydefault, Endevor uses the name, ENCOPTBL.

PARMLIB Indicates the Parmlib data set name, which isrequired to implement the Global Type Sequencingoption, because it is used to contain the TypeSequence member.




PDM Indicates whether the Endevor ParallelDevelopment Manager (PDM) facility is enabled atyour site. If your site is using PDM, specify Y.Otherwise, enter N.

For more information, see the PDM User Guide.

PKGDSN (Requiredentry if you are usingpackages)

The data set name of the VSAM file your site willuse to store package information. This library wascreated during the Endevor installation procedure.The recommended name is uprfx.uqual.PACKAGE.

The data set is required if your site plans to use anyof the package processing features.

For more information, see the Packages Guide.

Be sure you use the same data set name for bothdefinition of and allocation of the package data set.

PKGTSO Indicates whether foreground package processing isallowed. Set this parameter to Y if foregroundprocessing is allowed at your site. Otherwise, set theparameter to N.

When a processor runs as part of a package, thePKGTSO flag overrides the foreground executionflag in the processor group. This means that ifPKGTSO=Y, all processors in that package willexecute, regardless of the value in the foregroundexecution field for the processor group.

PKGCSEC Indicates whether actions should incur a securitycheck at package cast time. Set this parameter to Yto have each Endevor action checked during thepackage cast operation.

If you set this parameter to N, no action securitycheck is performed during the package castoperation.

PKGCVAL Indicates whether component validation is requiredwhen packages are cast. Values are:

■ Y—Component validation is required, no matterwho is working with the package.

■ O—Component validation is optional. Whethervalidation takes place is determined by theperson working with the package.




PKGSEC Indicates the type of security which controls thepackage options.

■ APPROVER—This value indicates that the sitewould like to restrict package actions to packageapprovers.

■ ESI—Indicates that the site would like tocontrol package options through an externalsecurity package such as ACF/2, Top Secret,and IBM RACF via the ESI interface.

■ MIGRATE—Indicates that the site is intransition between Approver security and ESIsecurity. Both will be checked.

Note: The approver security rules takeprecedence over ESI security rules. If the useris granted access to the package by the approverrules, ESI will not be invoked. ESI will beinvoked only when the user does not belong toany approver groups associated with thepackage (If there are no approver groupsassociated with the package (this is true forALL packages before they are CAST), no accessrestrictions apply.)

PRBLKSZ=0 Indicates the blocksize to be used for temporaryfiles when compiling processors. If you are on aversion of z/OS that does not support BLKSIZE=0,you must specify the value for this parameter that isa multiple of 121.

PRLNKSZ=(256K,64K) Indicates the size parameter used by the linkageeditor. When adding very large processors withmany symbolics, this parameter may need to beincreased. For example, use (384K,64K).

PRLSTSZ=10 The value of PRLSTSZ is used for both the primaryand secondary space allocation parameters (incylinders) for processor listings. The value ofPRLSTSZ may need to be increased for very largeprocessors.

PROC Indicates whether processors are enabled at yoursite. If your site is using processors, specify Y.Otherwise, enter N.

For more information, see the Extended ProcessorsGuide.




RACFGRP The name of the security group with which thealternate user ID (RACFUID) is associated. This isan optional parameter.

RACFPWD The security password for the defined alternate userID. This is an optional parameter.

RACFUID The alternate user ID for data set authorizationchecking.

RJCLROOT Controls the choice of remote JCL generation. Thereare three choices:

■ RJCLROOT - Not specified. Causes the jobstream to be programatically generated withoutthe use of model members.

■ RJCLROOT=FCPY which specifies the jobstream is generated through a set of modelmembers beginning with the character string#RJFCPY

■ RJCLROOT=ICPY which specifies the job streamis generated through a set of model membersbeginning with the character string #RJICPY

SITEID (Requiredentry)

The 1-character name that identifies your site. It isused internally to differentiate between sites.Default is 0 (zero).

SITEID is an integral part of the Endevor footprint.Any changes to this parameter for existing Endevorinstallations will result in a footprint-compromisederror for each element within that installation'senvironments.

SYMBOLTBL Indicates the name of the symbolics table in use atyour site if you are using site-defined symbolics.

For more information, see Site-Defined Symbolics inthe chapter “Site Symbolics.”

SMFREC# The SMF record number assigned to SMF recordswritten by ENDEVOR at this site. Set this value to 0(zero) until you implement the optional SMFinterface.

If you want to write out SMF Action Records orSMF Security Records or both, you must enter avalue for this parameter. The parameterscontrolling which records are actually written areSMFACT and SMFSEC in the TYPE=ENVRNMTmacro. For more information, see SMFACT.




SOFETCH Indicates whether the element that is fetched shouldbe signed out to you, if not already signed out tosomeone else Y, or not signed out N.

This value will come into play with Add (Fetch),Generate (Copyback), Move (Fetch), Transfer(Fetch), Search and Replace (Fetch) and Quick-Edit.

For a table that shows how SOFETCH valuestogether with actions affect signout, see the UserGuide.

SPFEDIT The queue name used when Endevor issues anenqueue on a sequential file or partitioned data set(not RECFM=U). This may be a source library,object library, or other user library. Default isSPFEDIT.

The resource name for the enqueue name is the dataset name.

SYSIEWL The queue name used when Endevor issues anenqueue on a partitioned data set defined withRECFM=U (for example, a load library). Default isSYSIEWL.

The resource name for the enqueue is the data setname.

TYPESEQMBR Indicates the name of the Type Sequence member,which enables Global Type Sequencing. The TypeSequence member defines the type sequence orderin which element actions are processed at your site,regardless of the action's inventory location. If youspecify this parameter, you must also specify theParmlib data set parameter. An empty TypeSequence member will force type sequencing bytype name order.

UIDLOC The character positions of the user ID that shouldbe compared for ownership (that is, for elementsignout and signout override check) in batch. Youspecify a starting position and number of characters.

For example, if you wanted to take the first threecharacters of the user ID, then you would specifyUIDLOC=(1,3). Default is the first seven characters:UIDLOC=(1,7).

VIOUNIT (Requiredentry)

The unit name for temporary disk data sets that arestored on a virtual I/O unit.




WRKUNIT (Requiredentry)

The unit name for temporary disk data sets that arenot stored on a virtual I/O unit.

WORKVOL The volume serial number of the disk used to storetemporary data sets.


13.6 The TYPE=ENVRNMNT Macro


The TYPE=ENVRNMNT macro defines environment information. You canhave any number of these macros in the table, but you must have one macrofor each environment in your configuration. The TYPE=ENVRNMNT macrosfollow the TYPE=MAIN macro.

The TYPE=ENVRNMNT macro is shown next:


ENDBACT=N, X

ENDBAVL=N, X

ENTRYSTG#=1, X

ENVNAME='Environment Name', X

ENVTITL='Environment Title', X

JRNLGRP=, X

NEXTENV=(Environment Name,Stage ID), X

RSCETBL=, X

SMFACT=N, X

SMFSEC=N, X

STG1ID=Stage 1 ID, X

STG1NME='Stage 1 Name', X

STG1TTL='Stage 1 Title', X

STG1VSM='Stage 1 MCF Data set name', X

STG2ID=Stage 2 ID, X

STG2NME='Stage 2 Name', X

STG2TTL='Stage 2 Title', X

STG2VSM='Stage 2 MCF Data set name', X

USERTBL=

To specify more than one environment, copy this macro as many times asnecessary.

Note: If you are creating an environment map, you need to specify the nextenvironment in each definition. Make sure that you code them in the properorder, starting with the first environment and continuing to the lastenvironment (in other words, start with the top and work down).



The following illustration shows an example for three environments:


.

.

.

USERTBL=


.

.

.

USERTBL=


.

.

.

USERTBL=

Each TYPE=ENVRNMNT macro is defined in the following table:


ENDBACTENDBAVL

Parameters related to the Endevor/DB-MVS Bridge.For more information, see the Endevor toCA-Endevor/DB Administrator Guide.

ENTRYSTG# Indicates the entry stage, either 1 or 2, for theenvironment. If this parameter is not defined, theentry stage defaults to 1.

ENVNAME(Required entry)

The 1- to 8-character name of the Endevorenvironment to which this macro applies. This valuemust be unique within this Defaults Table (that is, tothis site). The name can include any of (but only) thefollowing characters: A-Z, 0-9, @, #, $.

ENVNAME is an integral part of the Endevorfootprint. Any change to this parameter for existingz/OS environments will result in afootprint-compromised error for each element withinthat environment.

ENVTITL(Required entry)

The 1- to 40-character descriptive title for theenvironment.




JRNLGRP An L-Serv journal group ID which, when entered,relates the Master Control Files named in this macroto a specific set of L-Serv journal files. Use of thisparameter enables journaling in the Master ControlFile base and delta libraries (both VSAM andnon-VSAM).

The format is: (gggg,nnnn)

Values are:

■ gggg—The journal group ID associated with theMCF and delta journal files.

■ nnnn—The journal group subsystem ID.

For more information, see the Utilities Guide.

NEXTENV The next environment/stage location on theenvironment map. The format is: (environment name,stage id)

Values are:

■ environment name—The 1- to 8-character nameof the next environment.

■ stage id—The identifier (1 or 2) of the stage inthat environment. If you do not provide a stageID, Endevor defaults to STAGE ID=1.

For more information on maps, see the AdministratorGuide.

RSCETBL The 1- to 8-character name of the Endevor ResourceSecurity Table for this environment. The ResourceSecurity Table allows you to restrict one or moreelements to a specific system(s) and subsystem(s)within an environment. Define one Resource SecurityTable for each environment (as necessary).

Leave this field blank if you do not want to restrictelements to a specific system(s) and subsystem(s). Ifyou do want to use restriction, fill in this field andprepare the Resource Security Table as described inthe Security Guide (only applies to native security).




SMFACT Indicates whether Endevor should write out SMFAction Records. Set this parameter to Y if you wantAction Records written out. Otherwise, set theparameter to N. Default is N.

If you set this parameter to Y, you must specify avalue for the SMFREC# in the TYPE=MAIN macro. Ifyou do not specify SMFREC#, Endevor ignores theSMFACT parameter.

For more information on SMF Recording, see theAdministrator Guide.

SMFSEC Indicates whether Endevor should write out SMFSecurity Records. Set this parameter to Y if you wantSecurity Records written out. Otherwise, set theparameter to N. Default is N.

If you set this parameter to Y, you must specify avalue for the SMFREC# in the TYPE=MAIN macro. Ifyou do not specify SMFREC#, Endevor ignores theSMFSEC parameter.

For more information, see the Administrator Guide.

STG1ID (Requiredentry)

The 1-character identifier for the first stage, usedduring processing to select (or identify) the stage youwant. Commonly used identifiers are 1 or A. Defaultis 1.

STG1NME(Required entry)

The 1- to 8-character name assigned to Stage 1 forthis environment. The stage name must be uniqueacross all environments within a site (that is, withinthe Defaults Table). The stage name can include anyof (but only) the following characters: A-Z, 0-9, @, #,$.

Some commonly used Stage 1 names are: PREPROD,QA, STAGE1ID, and TEST.

STG1TTL(Required entry)

The 1- to 20-character descriptive title for the firststage. This name is used on various panels andreports to describe this stage.

STG1VSM(Required entry)

The Master Control File data set name for Stage 1, asdefined during installation. The data set namedefaults to: uprfx.uqual.STAGE1.

STG2ID (Requiredentry)

The 1-character identifier for the second stage, usedduring processing to select (or identify) the stage youwant. Commonly used identifiers are 2 or B. Defaultis 2.



Selecting a BATCHID Option: When executing Endevor element actions inbatch (C1BM3000), Endevor uses the values specified for BATCHID andUIDLOC in the C1DEFLTS table to derive the value to be used as the Endevoruserid.

The BATCHID parameter is specified in the TYPE=MAIN section of yourC1DEFLTS table. It determines whether the Endevor userid associated with abatch job will be determined by the JOBNAME, the USER= parameterspecified on the jobcard the userid of the submitter. One of the followingvalues must be specified:

■ 0-- determined by JOBNAME (this is the current default value, futurereleases will default to 2).

■ 1-- determined by the USER parameter, or if not present, the userid of thesubmitter.

■ 2-- determined by the USER parameter (or submitter as describedpreviously) if specified, otherwise by the JOBNAME.


STG2NME(Required entry)

The 1- to 8-character name assigned to Stage 2 forthis environment. The stage name must be uniqueacross all environments within a site (that is, withinthe Defaults Table). The stage name can include anyof (but only) the following characters: A-Z, 0-9, @, #,$

STG2TTL(Required entry)

The 1- to 20-character descriptive title for the secondstage. This name is used on various panels andreports to describe this stage.

STG2VSM(Required entry)

The Master Control File data set name for Stage 2, asdefined during installation. The data set namedefaults to: uprfx.uqual.STAGE2.

USERTBL The 1- to 8-character name of the Endevor UserSecurity Table for this environment. The UserSecurity Table allows you to control the systems andsubsystems available to all users within anenvironment. Define one User Security Table for eachenvironment (as necessary).

Leave this field blank if you do not want to controlsystems and subsystems within an environment. Ifyou do want to control the availability of systemsand subsystems, fill in this field and prepare theUser Security Table as described in the Security Guide(only applies to native security).



The UIDLOC parameter of the C1DEFLTS table (also TYPE=MAIN), tells usthe character positions of the Endevor userid that should be compared forownership, (that is, for element signout/override signout check) in batch.UIDLOC specifies the starting position and the number of characters. Thedefault is the first seven characters UIDLOC=(1,7).

In the following example, user PAND and user NDVR attempt to RETRIEVEan element that is currently "owned" by user NDVR. UIDLOC=(1,4). Neitheruser has the authority to use the "OVERRIDE SIGNOUT" option. Thefollowing chart shows the results of their attempts:

Userid Assigned by Endevor/Action Allowed (Y/N)

JOBNAME SUBMITTER USER= (1) BATCHID=� (2) BATCHID=1 BATCHID=2

ABCDJ PAND PAND ABCD/N PAND/N PAND/N

ABCDJ PAND n/a ABCD/N PAND/N PAND/N

ABCDJ NDVR NDVR ABCD/N NDVR/Y NDVR/Y

ABCDJ NDVR n/a ABCD/N NDVR/Y NDVR/Y

PANDJ PAND PAND PAND/N PAND/N PAND/N

PANDJ PAND n/a PAND/N PAND/N PAND/N

PANDJ NDVR NDVR PAND/N NDVR/Y NDVR/Y

PANDJ NDVR n/a PAND/N NDVR/Y NDVR/Y

NDVRJ PAND PAND NDVR/Y(2) PAND/N PAND/N

NDVRJ PAND n/a NDVR/Y(2) PAND/N PAND/N

NDVRJ NDVR NDVR NDVR/Y NDVR/Y NDVR/Y

NDVRJ NDVR n/a NDVR/Y NDVR/Y NDVR/Y

Notes

1. Several security packages have an optional feature to automatically appendthe user=/password= parameters on the job card at job submission. If thisis the case at your shop, then BATCHID=1 is recommended.

2. Many sites have job submission exits that ensure the jobname matches thesubmitter's userid. If your site does not utilize this feature, it is stronglyrecommended you DO NOT USE BATCHID=0.


13.7 The TYPE=END Macro

13.7 The TYPE=END Macro

The TYPE=END macro indicates the end of the table definition. It follows thelast TYPE=ENVRNMNT macro.

The TYPE=END macro is shown next:

C1DEFLTS TYPE=END

Do not change this macro.


Chapter 14. The Alternate Defaults Table

This chapter explains how to use the ENUXSITE exit to select an alternateEndevor Defaults Table.

Chapter 14. The Alternate Defaults Table 14-1

14.1 About ENUXSITE Program

14.1 About ENUXSITE Program

ENUXSITE is an exit, called at Endevor initialization, that allows your site toidentify the name of an alternate Defaults Table based on a user ID or othercriteria. An alternate Defaults Table might be used as a mechanism to test anew configuration at your site. Or, you may want to provide a specificDefaults Table for a group of users based on particular installation criteria.

Note:

■ The alternate Defaults Table must exist before you implement the exit.

■ The ENUXSITE program must be linked as an authorized program andmust reside in an authorized library.


14.2 Parameters Passed to the ENUXSITE Program

14.2 Parameters Passed to the ENUXSITE Program

When Endevor initializes a session, it searches the authorized library for auser-written program named ENUXSITE. If the program is found, Endevorpasses to the exit, using standard linkage conventions, a single, 16-characterdata field. The first eight characters of the field contain the name C1DEFLTS.The remaining eight characters contain the user ID associated with the currentEndevor session.

Note: When running in batch, the value specified as the user ID will be eitherone of the following:

■ The job name specified on the jobcard.

■ The value specified on the USER= parameter of the jobcard. This value, ifprovided, takes precedence over use of the job name.


14.3 How to Use the ENUXSITE Program

14.3 How to Use the ENUXSITE Program

There are two ways to select an alternate Defaults Table:

■ Modify the parameter by changing the first eight characters to the name ofthe Defaults Table you want to use. ENUXSITE returns control to Endevorto load the named table and use it as the Endevor Defaults Table.

■ Use the z/OS LOAD service to load an alternate table. Use the IDENTIFYservice to identify the table as the “C1DEFLTS.” The exit returns control toEndevor, leaving the 16-character parameter unmodified.


14.4 How to Create an Alternate Defaults Table

14.4 How to Create an Alternate Defaults Table

To create an alternate Defaults Table, follow the instructions provided in thediscussion “Step 8: Work with the Endevor Defaults Table.” Change the nameC1DEFLTS to the name you want to assign the alternate Defaults Table. Verifythat the link-edit output member name--DD SYSLMOD--specifies the correctname.


14.5 Example

14.5 Example

The following example shows a COBOL program written to allow USER1 tohave a different version of the Defaults Table than other users. The name ofUSER1's Defaults Table is TABLE1.IDENTIFICATION DIVISION.

PROGRAM-ID. ENUXSITE.

ENVIRONMENT DIVISION.

DATA DIVISION.

LINKAGE SECTION.

�1 LS-PARM-FROM-ENDEVOR.

�5 LS-TABLE-NAME PIC X(8).

�5 LS-USER-ID PIC X(8).

PROCEDURE DIVISION USING LS-PARM-FROM-ENDEVOR.

IF LS-USER-ID = 'USER1 '

THEN MOVE 'TABLE1 ' TO LS-TABLE-NAME.

GOBACK.


Chapter 15. Performance and Tuning

This chapter provides performance and tuning hints that can help you makeEndevor run efficiently in your environment.

Endevor's flexibility allows you to configure your system to meet your site'sgoals and standards.

Chapter 15. Performance and Tuning 15-1

15.1 Choosing Between Delta Formats


Full-Image delta format should be chosen for machine-generated code, USSbinary executables, or any source code where the compare is not appropriate.Change levels are not kept for Full-Image deltas, only full images of each level(like GDGs) are stored; therefore, full-image delta types may require moreDASD.

Both forward and reverse deltas allow you to keep track of the changes madeto an element, and they have the same performance characteristics in terms ofstorage. The difference is in what Endevor considers to be the base level.

■ For forward deltas, the base element is the original code, and the deltalevels correspond to the changes made to that code. When you want acopy of the latest version of an element, Endevor has to merge the baseand delta levels using the CONWRITE utility.

Forward deltas are useful when elements are relatively stable, becausewhen the element is saved, Endevor only writes the changes to a file anddoes not rewrite the full source text.

■ For reverse deltas, the base element is the current copy of the code, andthe delta levels contain the information needed to return the element to itsoriginal form. When you want a copy of the latest version of an element,Endevor (or any other program) can ignore the delta levels and simplyread the base element. This also improves processor performance, becauseEndevor does not need to invoke the CONWRITE utility to rebuild theelement.

Reverse deltas are useful when you are compiling an element frequently,because Endevor does not have to merge in the delta files. However,when an element is saved, Endevor has to replace the entire base level inaddition to saving the changes in the delta library.

Note: Backout processing requires a source output library that cannot be thesame data set as the reverse delta base library.



The following table summarizes the forward and reverse delta formats.

Note: For details about the conversion process, see Appendix A, “ConvertingDelta Formats.”

Delta Type I/Ooperationsneeded —Read

I/Ooperationsneeded —Write

Use for elements that:

Forward 2 1 ■ Are updated more than theyare read.

■ Are in production.

Reverse 1 2 Normally need a source outputlibrary but don't need to bebacked out. These files need tobe kept in a standard format(such as a PDS) for utilities suchas Advantage CA-File Master.


15.2 Setting the Element Delta Consolidation Level

15.2 Setting the Element Delta Consolidation Level

Element data consolidation is comprised of two functions: the "consolidationlevel" and the "number of levels to consolidate".

■ The consolidation level (CONSOL AT LVL) specifies when theconsolidation process is initiated. This is the maximum number of levelsyou want stored on the system.

Example: The CONSOL AT LVL parameter is set to 96. When thenumber of levels reaches 97, Endevor begins the consolidation process.

Note: For the most efficient level consolidation across environments, setthis parameter to the maximum value of 96.

■ The number of levels to consolidate (LVLS TO CONSOL) specifies thenumber of levels to consolidate when the threshold is met.

Example: The LVLS TO CONSOL parameter is set to 25, the CONSOL ATLEVEL (consolidation trigger) is set to 96. Prior to saving the 97th level,Endevor does the following:

– Merges levels 01 through 25 together to create a single delta level(level 01)

– Renumbers the remaining levels to 02 through 72

CONSOL AT LVL + 1 97

- LVLS TO CONSOL - 25

Minimum level 72

Determine the maximum and minimum number of levels you want to store onthe system. Using these values, you can calculate the number of levels toconsolidate (LVLS TO CONSOL). The maximum value is specified in theconsolidate level (CONSOL AT LVL) field. The minimum value is only usedfor calculation purposes. The difference between the maximum value and theminimum value is the number of levels to consolidate (LVLS TO CONSOL).

Maximum level (CONSOL AT LVL)

- Minumum level

Levels to consolidate (LVLS TO CONSOL)

The larger the number of levels you retain, the longer it takes Endevor torebuild, because each delta level requires additional I/O operations.

Note: Verify the parameter values match for the same element type acrossdifferent Endevor locations. For information on where to set the consolidationlevel, see 3.7.3, “Type Definition Panel” on page 3-34.


15.3 Mapping Multiple Environments

15.3 Mapping Multiple Environments

This section explains how to map multiple environments in Endevor.

Before Implementation: Before implementing Endevor, determine thenumber of environments you need, and how the stages within thoseenvironments are connected. By examining your site's requirements, you canbuild a software life cycle that provides the most efficient path for yourdevelopers.

For example, the following diagram shows two environments (QA and PROD)with links between the first and second stage in each environment, andanother link between stages HOLD and PROD.

This model cannot be implemented using the basic Endevor pathways, becauseyou can only enter an environment through a single entry stage. If developerswanted to move an element from Stage HOLD to Stage PROD, they must usethe TRANSFER action instead of the familiar MOVE action. In order to solvethis problem, you can create Stage 2 to Stage 2 links by mapping theenvironments in the Defaults Table. Mapping allows you to: do the following:

■ Create the logical equivalent of n stages.

■ Provide developers with the ability to MOVE, ADD, and RETRIEVEelements between the linked stages.

■ Create multiple entry points into a software life cycle or join multiple lifecycles.

■ Carry footprints and component lists across environments.

■ Enforce Signin and Signout procedures across environments.

■ Allow for copyback and integrity checking across environments.

For more information on mapping, see the chapter “Mapping.”


15.4 Selecting a Library Type for Base and Delta Members


You can store your Endevor data sets using PDS, PDS/E, Endevor LIB(VSAM/BDAM), or AllFusion CA-Panvalet and AllFusion CA-Librarian. Thissection discusses the benefits and drawbacks of each library type.

15.4.1 Benefits and Drawbacks of Library TypesThe following table lists the benefits and drawbacks of each library type:

Medium Benefits Drawbacks

PDS ■ Provides a familiar andstandard means ofstorage for the source.

■ No installation issues.■ Members can be read

by other utilities suchas compilers.

■ Directory overheadbecomes inefficient ifthere are more than3-4K+ members.

■ Strict maintenance isrequired to prevent x37abends.

PDS/E ■ Low maintenance. ■ Current technology.■ Members can be read

by other utilities suchas compilers.

■ Benchmarks show thatthe performance isslower than PDS orEndevor LIB.

■ Does not allow EXCPprocessing.



Medium Benefits Drawbacks

Endevor LIB ■ Low maintenance.■ Sophisticated set of

utilities to manage thedata sets.

■ BDAM is more efficientfor medium-sizeddirectories, and VSAMis more efficient forlarge directories, thaneither PDS or PDS/E.

■ Directory overheadroutines are designedfor a large number ofmembers, therebyincreasing efficiency.

■ You can allocate aVSAM ELIB acrossmultiple volumes. Ifyou initially allocate anELIB data set acrosstwo volumes, Endevorwill honor thatallocation when ELIBexpansion occurs. Theexpansion can beautomatic when thepage reserve limit isreached or explicitlyperformed through theuse of BC1PNLIB. Thisis only for VSAM ELIB;BDAM ELIB must beallocated on a singlevolume.

■ VSAM options canrequire a lot ofprocessing time.

■ Utilities are required forexpands, copies, etc.

■ Library membersaccessible only throughEndevor.

AllFusionCA-Panvalet/AllFusionCA-Librarian

■ Accommodates the sitestandard.

■ Directory compressionissues are eliminated.

■ Source output file canbe read directly byAllFusionCA-Panvalet/AllFusion CA-Librarianutilities.

■ With AllFusionCA-Panvalet, conflictsarise with Endevorfootprint and commentinformation.

■ Library members areonly accessible throughAllFusion CA-Panvaletand/or AllFusionCA-Librarian.



15.4.2 Converting from One Library Type to AnotherThe BC1PNCPY utility copies data from one of the supported library format toanother supported format. This allows you to try different methods based onyour site's requirements. For example, you can copy an AllFusionCA-Panvalet library to a PDS, or copy a PDS to Endevor LIB.

For more information about the BC1PNCPY utility, see the Utilities Guide.


15.5 Using CA-L-Serv for Endevor's VSAM File Processing


CA-L-Serv is a master started task that controls Endevor's VSAM files forMaster Control Files (MCFs), packages, and Endevor LIB (if you are usingVSAM processing instead of BDAM processing). It:

■ Allows for normal VSAM tuning.

■ Reduces the number of file I/O operations such as opens, closes, verifies,enqueues, and dequeues.

■ Provides the following standard services:

– Cross-system communications.

– Automatic job scheduling.

– Centralized logging facilities.

15.5.1 Setting the RECBUFFSIZE ParameterWhen you install CA-L-Serv, set the RECBUFFSIZE parameter based on yoursite's configuration. If you are using CA-L-Serv to manage:

■ Only MCFs and package data sets, set RECBUFFSIZE to 1K (the size of thelargest VSAM record in these files).

■ Endevor LIB VSAM files (with or without MCFs or packages), setRECBUFFSIZE to the block size of the largest library file being managed(normally, this is 4K).

Note: If you are using Point in Time Recovery, set RECBUFFSIZE to 12K.Internally, Endevor blocks all non-VSAM Base/Delta records before writing tothe journal files in 12K increments.

15.5.2 Monitoring CA-L-Serv's PerformanceThe ongoing success of this feature requires periodic monitoring to ensure thatoptimal performance benefits are achieved. You should monitor the systemwhen the following changes occur:

■ Any significant additional Endevor load is added (for example,environments and elements).

■ Any significant Endevor data set reconfiguration takes place (for example,splitting of Base/Delta's or changing from PDS to VSAM E-Lib).

■ Any system hardware or software changes are made (for example, VTAM,CPU, or the operating system).

For details about CA-L-Serv's monitoring facilities, see the Unicenter CommonServices CA-L-Serv Technical Bulletin.



15.5.2.1 Evaluating Buffer Pool Usage

To see how well your buffer pools are being used, issue the DISPLAYBUFFERPOOL and DISPLAY STATISTICS SERVICE commands. For details,see the Unicenter Common Services CA-L-Serv Technical Bulletin.

15.5.2.2 Displaying Information about the Communications Server

The DISPLAY command provides additional options to provide onlineinformation about the Communication Server's activity. For details, see theUnicenter Common Services CA-L-Serv Technical Bulletin.


15.6 Using z/OS SYSPLEX VSAM Record Level Sharing (RLS) Support for MCFs and Package Data Set

15.6 Using z/OS SYSPLEX VSAM Record Level Sharing (RLS)Support for MCFs and Package Data Set

VSAM record level sharing (RLS) extends the DFSMS/MVS storage hierarchyto support data sharing across multiple systems in a System/390 parallelSysplex. This feature, available on all z/OS Sysplex systems, offers Endevorthe performance and availability benefits of data sharing in a coupled-systemsenvironment.

As a new data access mode, VSAM RLS allows multisystem access to a VSAMdata set while ensuring cross-system locking and buffer invalidation. VSAMRLS uses z/OS coupling facility (CF) services to perform data set level locking,record locking, and data caching. VSAM RLS maintains data coherency at thecontrol interval level. It uses CF caches as store-through caches; when acontrol interval of data is written, it is written to both the CF cache and toDASD. This ensures that a failure in the CF cache does not result in the lossof VSAM data.

The SMSVSAM server is a new system address space used for VSAM RLS.The data space associated with the server contains most of the VSAM controlblocks and the system-wide buffer pool used for data sets opened forrecord-level sharing. SMSVSAM assumes responsibility for synchronizing thiscontrol block structure across the parallel Sysplex.

With VSAM RLS, multiple Endevor systems can directly access a sharedVSAM data set, eliminating the need for Reserve/Release and Enqueuesbetween Endevor Users or Batch Jobs in order to maintain the integrity of theEndevor VSAM data sets. VSAM RLS provides for serialization andsynchronization of data sets and cross-system caching. With VSAM RLS,multiple Endevor Users or Batch Jobs can have concurrent read/write access toEndevor VSAM data sets

A new attribute, LOG, defines a data set as recoverable or non-recoverable.Because Endevor does not use CICS compatible Recovery, Logging orJournaling, the LOG attribute must be set to LOG(NONE).

At OPEN time, Endevor determines if the file is defined with VSAM RLSsupport, and, if so, Endevor opens the file with RLS.

System administration determines when RLS is used. Typically, thisdetermination is made when the cluster is defined with the IDCAMS utilityprogram.

Sample JCL to enable RLS support may be found in iprfx.iqual.JCLLIB, memberBC1JDRLS.


15.6 Using z/OS SYSPLEX VSAM Record Level Sharing (RLS) Support for MCFs and Package Data Set

VSAM Record Level Sharing provides the following performanceenhancements:

■ The VSAM buffers for ALL jobs and/or TSO users are consolidated intothe SMSVSAM address space, increasing the chance of a record being inmemory

■ The SYSPLEX Lock Manager provides record level, CI level and CA levellocking between SYSPLEX systems

■ Due to the first two enhancements, Endevor is able to bypass its ownnative Reserve/Release logic

■ The I/O performance of the SMSVSAM address space and the SYSPLEXcache allows a significant reduction in the elapsed time required to doupdate I/Os.

Implementing RLS: Endevor provides RLS support for Master Control Files(MCFs) and the Package dataset.

In order to use Endevor with RLS managed datasets, certain dataset attributesmust be used when allocating the VSAM cluster. As previously mentioned,LOG (NONE) must be part of the definition. Also, a share attribute of (1,3)must be part of the cluster definition.


15.7 Tuning Your Processors

15.7 Tuning Your Processors

This section lists the points that you need to keep in mind while tuning yourprocessors.

Recommendations: When you are tuning your processors, you should keepthe following points in mind:

■ Ensure that record formats (RECFMs), block sizes (BLKSIZEs), and logicalrecord lengths (LRECLs) are specified correctly for the program beingexecuted.

Note: The operating system provides the "System Determined BLKSIZE"facility, which selects the best block size for a data set (based on its RECFM,LRECL, and the track size DASD device) if it is allocated with BLKSIZE=0.You can use this facility with any Endevor data sets except for linkage-editordata sets.

■ Avoid recursive executions of Endevor by making use of the CONWRITEutility to output other elements. For example, if your jobcards are storedin one file and need to be merged into every executable file, CONWRITEcan perform this merge without re-invoking Endevor. For moreinformation about CONWRITE, see the Extended Processors Guide.

■ Streamline processors by taking advantage of instream data (for example,DD *) and symbolics (for example, &C1SYSTEM). This eliminates extrasteps that may have been required in the past.

■ Allocate all temporary sequential data sets with BC1PDSIN to ensure thatthey are available for other programs such as CONLIST. Allocate otherdata sets using traditional JCL statements for each step.

■ Ensure that your JCL dispositions are properly coded to release data setswhen appropriate (for example, use FREE=CLOSE).

■ Delete outputs with CONDELE wherever possible.


15.8 Tuning Your System


This section lists the points that you need to keep in mind while tuning yoursystem.

Recommendations: When you are analyzing the general environment, keepthese points in mind:

■ Ensure that VSAM and all output libraries are properly located,maintained, and sized. Poorly tuned VSAM files can seriously degradeperformance, so:

– Examine LISTCAT to analyze CA/CI splits, and reorganize ifnecessary.

– For highly accessed VSAM files, move the index to a cache device(remember to deimbed the index first).

– DO NOT alter the attributes of the VSAM Master Control File (MCF)unless you are using CA-L-Serv.

■ Tune the physical placement and attributes of your files:

– Highly volatile files, such as those in development locations, performbetter near the beginning of the string, while more stable files, such asthose in production locations, can be located near the end of the string.

– Analyze how many files reside on a single pack, and how large theyare. You should split Endevor files across multiple packs, and ensurethat no other large files (such as the system catalog) share the pack.

– Ensure that your file allocations are the most efficient ones for yoursystem.

■ Consider deleting and reallocating processor outputs for major systemregenerations.

■ Process concurrently whenever possible. For example, if you want torecompile the entire system, specifying GEN ELEM A* K* and GEN ELEML* Z* instead of GEN ELEM A* Z* allows the system to process bothhalves at the same time.

■ Consider using other products to help improve library performance. Forexample, CA developers had an unload that required 90 minutes withEndevor. When they combined Endevor with two other CA products,Unicenter CA-PMO and Unicenter CA-QuickFetch, the unload took only 12minutes. Unicenter CA-PMO eliminates more than 90% of the directorysearch I/Os for libraries and PDSs, while Unicenter CA-QuickFetcheliminates more than 90% of the fetch I/O for load modules in anymanaged program library.

■ Define VSAM MCFs in the skeleton library using DISP=OLD to eliminatemultiple opens, closes, enqueues, and dequeues.



■ LRECL setting for variable block files:

The output records from the compression routine CONCOMP3 can belarger than the input records when the input files contain binary datauploaded from other machines, or already compressed data (output fromTRSMAIN).

While it is not possible to predict the maximum increase in size ofCONCOMP3 records, we have never seen a record increased by more than1.6 times the size of the input record. Because the size of the output recorddepends on the input data, we can make predictions for specific inputrecords, and suggest that you use the following recommendations forsetting variable block files.

– Set the block size (BLKSIZE) for variable block files to 27998, which ishalf a disk 3390 track. This size allows very rapid I/O time and veryefficient space usage. The reason for this is that MVS will put as manyrecords as possible in the buffer defined by the BLKSIZEs and willonly write the block if the remaining space cannot hold the nextrecord. If a BLKSIZE of 2550 is chosen, then it will hold a maximum of2546 bytes; however small BLKSIZEs are inefficient for disk use andalso inefficient in I/O time.

– The logical record lengths (LRECLs) for variable block files should beat least 4 less than 27998 (that is, 27994). MVS will use what it needsand as long as the buffer allocation (LRECL'value) is big enough, itwill fit without problems or wasting space. There is no reason toreduce the LRECL to 255, for example. For variable or variable blockfiles, the actual LRECL is not important. The LRECL does not definethe length of the records. The actual size is defined in the recordsthemselves. The LRECL defines the maximum length of any onerecord. As a consequence, setting a larger LRECL and BLKSIZE forvariable block files is not a problem. As long as the LRECL is largerthan the actual record, the record will fit.

– The LRECL for input records that contain binary content should have amaximum LRECL of 13K. Then, the compression results can be twiceas big and still fit in the buffer. Since the LRECL of these uncommoninput files is usually arbitrarily chosen, we recommend keeping themsmaller than 2K, which is more efficient when Endevor does sourcecompares.


Appendix A. Converting Delta Formats

This appendix explains the steps for converting one delta format to another. Itcontains the following sections:

■ Steps for converting forward to reverse delta

■ Additional conversion notes

■ Procedure for converting forward/reverse delta to full-image delta

Appendix A. Converting Delta Formats A-1

A.1 Steps for Converting Forward to Reverse Delta


This section explains the steps for converting forward delta format to reversedelta format.

A.1.1 Procedure SummaryConversion to reverse delta format should be planned carefully. The steps inconversion are summarized here, then described in detail in the followingsections.

1. Analyze existing types to determine which are likely to benefit fromconversion.

2. Resize and allocate new base libraries for these types.

3. Resize the delta libraries.

4. Evaluate and modify processors.

5. Run a full unload for each environment.

6. Adjust the definitions of these types to reflect the conversion. Make thenecessary changes to the library names on the Type Definition panel.

7. Reload by system to populate the new libraries.

8. Run the Validate utility to confirm results.

A.1.2 Step 1: Analyzing Existing TypesUse reverse deltas for the types that:

■ Normally need a source output library but do not need to be backed out(CA Endevor does not backout/backin base/delta libraries).

■ Need to be kept in standard PDS format for utilities, such as AdvantageCA-File Master.

■ Are used exclusively on the workstation.

Types that can benefit from the reverse delta storage format include thefollowing:

■ Copybooks

■ JCL

■ Source

A-2 Administrator Guide


Use forward deltas for types that:

■ Have no external access requirements.

■ Can benefit from being compressed.

■ Can benefit from being shared (encrypted).

A.1.3 Step 2: Resize and Allocate New Base LibrariesSince the element base is the current image in reverse delta format, separatebase libraries are required for each type in a particular stage. Whenreallocating your base libraries, keep the following in mind:

■ Plan the library structure first. Keep a record of the plan for use whenupdating type definitions.

■ Make sure that LRECL, BLKSIZE, and RECFM parameters are appropriateto the type being converted (see the existing source output libraries).

■ Keep in mind non-compression when planning space requirements.

■ Make sure to plan for and allocate new base libraries for every type withina system. Make sure that the new libraries map properly to stage and typerequirements.

■ When planning for workstation types, remember that most mainframecompilers require LRECL=80.

A.1.4 Step 3: Resize the Delta LibrariesResize the delta libraries to account for movement of the base component listmember to the delta library. The resizing requires space revisions to both thefile and the directory.

A.1.5 Step 4: Evaluate and Modify ProcessorsEvaluate your processors, keeping in mind the following:

■ The CONWRITE step can be eliminated when using reverse deltas.

■ The CONWRITE step, when used, needs to be modified to take account ofrevised Include libraries.

■ Processors can read the base library directly when reverse deltas are beingused.

A.1.6 Step 5: Run a Full Unload of Each EnvironmentTo capture all elements, perform a full unload (BC1JUNLD) against eachenvironment or, optionally, by system for large installations.



A.1.7 Step 6: Adjust Type DefinitionsAfter unloading all affected elements, change the type definitions on the TypeDefinition panel for those types that you want to store in reverse delta format.Change the following:

■ FWD/REV DELTA field to R (reverse).

■ COMPRESS BASE/ENCRYPT NAME field to N (no).

■ SOURCE LENGTH, COMPARE FROM, and COMPARE TO fields to thedesired values.

■ FWD/REV delta setting in the COMPONENT LIST OPTION field(optional).

■ Library definitions as necessary to reflect new base libraries and optionalchanges to include and source output libraries. Use the informationrecorded in Step 2.

These fields are in bold type in the Type Definition panel shown next:


COMMAND ===>




UPDATED: BY

----------------- ELEMENT OPTIONS -------------------

FWD/REV/IMG DELTA ===> R (F/R/I) COMPRESS BASE/ENCRYPT NAME ===> Y (Y/N)DFLT PROC GRP ===> CLENBL REGRESSION PCT ===> 75 REGR SEV ===> W (I/W/C/E)

SOURCE LENGTH ===> 8� COMPARE FROM ===> 7 COMPARE TO ===> 72AUTO CONSOL ===> Y (Y/N) LANGUAGE ===> cobol PV/LB LANG ===> DATA

CONSOL AT LVL ===> 96 HFS RECFM ===> NL (COMP/CR/CRLF/F/LF/NL/V)

LVLS TO CONSOL ===> 49 DATA FORMAT ===> B FILE EXT ===>




--------------------- LIBRARIES ---------------------

BASE/IMAGE LIBRARY ===> CA.ENDEVOR.SMPL&C1ST..BASEDELTA LIBRARY ===> CA.ENDEVOR.SMPL&C1ST..DELTA

INCLUDE LIBRARY ===>SOURCE O/P LIBRARY ===>EXPAND INCLUDES ===> N (Y/N)

� �

A.1.8 Step 7: Reload Inventory by SystemExecute the Reload utility (BC1JRELD) by system to populate the new librarieswith your inventory.



A.1.9 Step 8: Validate the ResultsExecute the Validate utility (BC1JVALD) to confirm the results.


A.2 Additional Conversion Notes

A.2 Additional Conversion Notes

Keep in mind the following when converting to reverse delta format:

■ Elements are stored in the new storage format after the first sourceUPDATE following the conversion.

■ Component lists are stored in the new storage format after the firstGENERATE action is executed against the element following either achange in an input component or a source update.

■ The current delta format for an element appears on panel 1 of the ElementMaster display.

■ Source messages related to forward/reverse delta conversion are inSMGRnnnn format.


A.3 Procedure for Converting Forward/Reverse Delta to Full-Image Delta

A.3 Procedure for Converting Forward/Reverse Delta toFull-Image Delta

If you want to change the delta format of an existing type fromforward/reverse to full image, and the type has elements associated with it,you must do the following:

■ Define a new type as full image delta format

■ Transfer the elements to the new type

If types are mapped with different delta formats, the WITH HISTORY optionmay or may not be an option. The following table shows when the WITHHISTORY option can be used for a MOVE or TRANSFER when types withdifferent delta formats are mapped together:

SourceFormat

TargetFormat

MOVEwithhistory

MOVEwithouthistory

TRANSFERwithhistory

TRANSFERwithouthistory

Full-image Full-image Yes Yes Yes Yes

Full-image Reverse No Yes No Yes

Full-image Forward No Yes No Yes

Reverse Full-image No Yes No Yes

Forward Full-image No Yes No Yes


Appendix B. Catalog Utilities

CA Endevor uses an Element Catalog file to support long element names andto boost performance by reducing the volume of I/O operations.

Appendix B. Catalog Utilities B-1

B.1 Building the Element Catalog


In moving to CA Endevor r7 from release 3.9 or earlier, you need to performseveral post-installation steps to prepare for implementing r7. These steps aresummarized in the following table and described in detail in the followingsections.

Step What You Do JCLLIBMember/JOB

1 Copy all your MCF VSAM data set tonew data sets with r7 VSAM attributes.

BC1JXMCF

2 Copy your Package VSAM data set to anew data set with r7 VSAM attributes.

BC1JXPCF

3 Define CA Endevor's r7 catalog VSAMdata set.

BC1JJB07

4 Add the ELMCATL= catalog parameterto the C1DEFLTS table.

BC1JDEFT

5 Run CA Endevor's Catalog Build utilityagainst all defined Environments.

BC1JXCNV

B.1.1 Step 1: Converting Your Existing MCF VSAM Data SetsThe MCF data set's maximum record length has changed from release 3.9 andearlier. As a result, you must redefine all your stage MCFs for all yourenvironments. Use member BC1JXMCF from your CA Endevor JCL Library totailor the job stream for all your MCF file conversions. This job backs up yourexisting data sets to sequential files, deletes and redefines the MCF VSAMfiles, then populates the records back into your newly-defined MCF fileclusters. This job is set up to handle a single environment. You need tomodify it to include all the environments defined at your site.

B.1.2 Step 2: Converting Your Existing Package VSAM Data SetsThe Package data set's maximum record length has also changed from release3.9 and earlier. Use member BC1JXPCF from your CA Endevor JCL library totailor the job stream to do your package file conversion. This job backs upyour existing data set to a sequential file, deletes and redefines the packagefile, populates the newly-defined VSAM package file with your package data.

B-2 Administrator Guide


B.1.3 Step 3: Defining the MCF Catalog Data SetBeginning with Release 4.0, a catalog data set is used to keep track of elementsacross all defined environments in your C1DEFLTS. Use member BC1JJB07from your CA Endevor JCL library to define the catalog data set. You willneed to tailor the job stream based upon your installation's needs.

Note: Once you convert to Release 4.0 or above, you must not use a 3.9release or earlier release to access Release 4.0 or r7 data. If you do, the catalogbecomes out of sync with the MCFs.

B.1.4 Step 4: Updating the C1DEFLTS TableUpdate your C1DEFLTS table to identify your element catalog data set to CAEndevor by using the ELMCATL parameter. Remember to compile and link itinto your site's proper authorized library.


ELMCATL='CA.PROD.ELMCATL', X

B.1.5 Step 5: Running the Catalog Build UtilityRun the catalog utility to populate the catalog data set with elementinformation. This utility should only be run during the conversion processand it must be run against all environments defined in your C1DEFLTS table.

BC1PXMCS allows you to selectively choose the environments you want topopulate. You can run it against each environment separately or against allenvironments collectively in a single step. Before you

begin to use CA Endevor r7, you must have run the conversion utility againstall environments defined in your C1DEFLTS table.

Use member BC1JXCNV from your CA Endevor JCL library to tailor the jobstream to do your initial build of the element catalog. Before running this job,you should have the authority to access all the environments that you want topopulate. If you do not have the authority to access an environment, thecontents of catalog data set will be incomplete and it may result in "elementnot found" errors. The output report of running the BC1JXCNV job is writtento BSTLST. This report contains the number of catalog segments read andwritten to the catalog data set.

Sample Output Report: This section describes the sample ouput of runningthe BC1JXCNV utility that loaded an empty catalog data set from a C1DEFLTStable, containing two environments, TEST and PROD. The output generated byBC1PXMCS, BC1PXCCS, and BC1PXCSC to BSTLST is described next.



BC1PXMCS in step 3 creates element segment records from MCFS andgenerates the following report:

CA Endevor MCF Conversion Element Extract UTILTIY LOG

MCF CATALOG SEGMENT DATA WILL BE CREATED FOR ENVIRONMENT TEST

NUMBER OF CATALOG SEGMENTS WRITTEN FOR ENVIRONMENT TEST: 9243

MCF CATALOG SEGMENT DATA WILL BE CREATED FOR ENVIRONMENT PROD

NUMBER OF CATALOG SEGMENTS WRITTEN FOR ENVIRONMENT PROD: 5978

TOTAL NUMBER OF CATALOG SEGMENTS WRITTEN, ALL ENVIRONMENTS: 15221

BC1PXCCS in step 4 extracts segment records and produces the followingreport:

CA Endevor Catalog Segment Extraction UTILITY LOG

CCS��8I TOTAL NUMBER OF CATALOG SEGMENTS READ: �

CCS��9I TOTAL NUMBER OF CATALOG SEGMENTS WRITTEN: �

If you are loading an empty catalog data set, the number of catalog segmentsread and written should be zero.

BC1PXCSC in step 6 creates catalog records from the catalog segments andgenerates the following output:

CA Endevor MCF Element Segment Conversion to Catalog Format UTILITY LOG

TOTAL NUMBER OF ELEMENT ENTRIES READ, ALL ENVIRONMENTS: 15221

TOTAL NUMBER OF CATALOG ENTRIES WRITTEN, ALL ENVIRONMENTS: 13366

TOTAL NUMBER OF ELEMENT INDEX RECORDS WRITTEN, ALL ENVIRONMENTS: 1�183

You can also use the BC1JXCNV utility to add a new, populated environmentto an existing C1DEFLTS table and catalog data set. In the following sampleoutput, the ARCHIVE environment is added to an existing catalog data set.The output reports produced by step 3, step 4 and step 6 are described next.

BC1PXMCS in step 3 generates the following output:

CA Endevor MCF Conversion Element Extract UTILTIY LOG

ENV ARCHIVE

MCF CATALOG SEGMENT DATA WILL BE CREATED FOR ENVIRONMENT ARCHIVE: 75

TOTAL NUMBER OF CATALOG SEGMENTS WRITTEN, ALL ENVIRONMENTS: 75

BC1PXCCS in step 4 generates the following output:

CA Endevor Catalog Segment Extraction UTILITY LOG

NUMBER OF CATALOG SEGMENTS WRITTEN: 25��






TOTAL NUMBER OF CATALOG SEGMENTS READ: 15221

TOTAL NUMBER OF CATALOG SEGMENTS WRITTEN: 15221



BC1PXCSC in step 6 generates the following output:

CA Endevor MCF Element Segment Conversion to Catalog Format UTILITY LOG

TOTAL NUMBER OF ELEMENT ENTRIES READ, ALL ENVIRONMENTS: 15296

TOTAL NUMBER OF CATALOG ENTRIES WRITTEN, ALL ENVIRONMENTS: 1342�

TOTAL NUMBER OF ELEMENT INDEX RECORDS WRITTEN, ALL ENVIRONMENTS: 1�215


B.2 CA Endevor Considerations

B.2 CA Endevor Considerations

Beginning with Release 4.0, the following considerations apply:

■ "NEXT TYPE" name can no longer differ from "this" TYPE (No type namechanges across the map are allowed.)

■ If long element names are used, the LRECL of the delta library must be atleast 259.

■ RLS or CA-Lserv implementation is highly recommended for the CAEndevor Catalog data set, MCFs and the PCF (Package Control File).

■ Due to the key structure of the catalog, it is highly recommended thatelement searches are done with an element and type specification. (Thecatalog key is element name + type name.)

■ CA Endevor releases 4.0 and r7 are downwardly compatible with CAEndevor R3.9, provided none of the new features have been implemented(long element names, site symbolics, HFS pathnames, and so on).

■ CA Endevor control tables (C1DEFLTS, ENDICNFG, ENCOPTBL, etc.) arevalidated at CA Endevor start-up time to ensure all tables are releasecompatible.

■ The Element Registration feature can be activated in WARN, CAUTION orERROR mode (and switched from one mode to the other at any time).


B.3 Catalog Rename Utility


The CA Endevor MCF Catalog Rename Utility allows you to change thecatalog name in the MCF's stage record. This utility should be run after youhave created a new catalog and have defined it to the C1DEFLTS table.

With the implementation of the Element Catalog, all MCF's have the catalogname recorded in its stage record. The first time CA Endevor is invoked aftermigration from a prior release, the MCF's, at open time, are updated with theElement Catalog name. From that point on, (at open time) CA Endevor checksthe stage record's catalog name against the name specified in the C1DEFLTStable. If the names are not equal, the MCF open fails. This check preventsMCF's from belonging to more than one catalog.

The CA Endevor MCF Catalog Rename Utility allows you to change thecatalog name in the MCF's stage record. This utility should be run after youhave created a new Catalog and have defined it to the C1DEFLTS table.

The utility can run in following two modes:

■ ValidateMode — All environments defined in the C1DEFLTS table areexamined. A report is produced showing the current MCF catalog nameand a statement as to whether or not the name agrees or disagrees withthe C1DEFLTS table. A return code of 0 indicates all environments matchthe table's definition. A return code of 4 indicates that some or allenvironments are not current with the table's definition.

■ Update Mode — All environments defined in the C1DEFLTS table areexamined, but instead of just reporting the mismatches, the utility rewritesthe stage records with the name defined from the C1DEFLTS table. Areturn code of 0, under Update mode, indicates that all environmentsmatch the table's definition. A return code of 4 indicates that some or allof the stages were updated with the table's name.

To execute the rename utility, use member BC1JXCNM from your JCL library.To invoke validate or update mode, change the PARM= parameter on theexecute statement.



Catalog Rename Utility Sample Report: The following is a sample reportproduced by Catalog Rename Utility:

ENDEVOR Stage Catalog Name Update/Validation UTILITY LOG

Endevor Catalog Name: CA.ENDEVOR.ELMCATL

Run Mode: VALIDATE

ENVIRONMENT ENV1 STAGE 1 CATALOG NAME CA.ENDEVOR.ELMCATL.............................. AGREES WITH C1DEFLTS TABLE.


ENVIRONMENT ENVA STAGE 1 CATALOG NAME CA.ENDEVOR.ELMCATL.............................. AGREES WITH C1DEFLTS TABLE.


CNM��12I ALL STAGES AGREE WITH THE C1DEFLTS CATALOG NAME, NO UPDATE IS NECESSARY

CNM��14I TOTAL NUMBER OF ENVIRONMENTS PROCESSED: 2

CNM��17I NUMBER OF STAGES THAT DO NOT MATCH THE NEW C1DEFLTS CATALOG NAME: �

CNM��16I NUMBER OF STAGES THAT MATCH THE NEW C1DEFLTS CATALOG NAME: 4


Endevor Catalog Name: CA.ENDEVOR.ELMCATL

Run Mode: UPDATE





CNM��1�I NO STAGE RECORDS UPDATES WERE NECESSARY, ALL SET WITH THE CURRENT CATALOG NAME


CNM��15I NUMBER OF STAGES UPDATED TO NEW C1DEFLTS CATALOG NAME: �

CNM��16I NUMBER OF STAGES THAT MATCH THE NEW C1DEFLTS CATALOG NAME: 4


CA Endevor Catalog Name: CA.PROD.ELMCATL

Run Mode: UPDATE

ENVIRONMENT ENV1 STAGE 1 CATALOG NAME CA.ENDEVOR.ELMCATL.............................. DIFFERS FROM C1DEFLTS TABLE.

ENVIRONMENT ENV1 STAGE 2 CATALOG NAME CA.ENDEVOR.ELMCATL.............................. DIFFERS FROM C1DEFLTS TABLE.

ENVIRONMENT ENVA STAGE 1 CATALOG NAME CA.ENDEVOR.ELMCATL.............................. DIFFERS FROM C1DEFLTS TABLE.

ENVIRONMENT ENVA STAGE 2 CATALOG NAME CA.ENDEVOR.ELMCATL.............................. DIFFERS FROM C1DEFLTS TABLE.

CNM��11I STAGE UPDATES WERE NECESSARY, NOT ALL AGREED WITH CATALOG NAME ENTRY IN C1DEFLTS


CNM��15I NUMBER OF STAGES UPDATED TO NEW C1DEFLTS CATALOG NAME: 4

CNM��16I NUMBER OF STAGES THAT MATCH THE NEW C1DEFLTS CATALOG NAME: �


B.4 Catalog Synchronization Utility


The CA Endevor Catalog Synchronization Utility allows you to update theelement catalog to recover differences between the element catalog and itsrelated MCF files.

This utility has two modes, a validate mode and an update mode. Thevalidate mode simply reports on the differences between the catalog and MCFfiles. The update mode actually recovers the differences between the elementcatalog and its related MCFs by updating the element catalog file.

Under the update mode, the utility synchronizes the element catalog and theMCF element records in two phases.

The first phase validates MCF records against the catalog. A catalog segment iscreated for any MCF record found missing from the catalog. A catalogsegment is updated with MCF element data when the associated catalog datais found to be different.

The second phase validates the catalog to MCF in order to remove deadsegments from the catalog. All segments which do not have a MCF elementrecord are removed from the catalog.

Under validate mode, the utility performs the same two-phase check but doesnot modify the catalog. Any differences are simply reported in the executionlog.

To select the mode, use the PARM= parameter on the JCL execution statement.

In both phases, processing is done by environment. You can specify whichenvironments the utility will process, or allow the environment selection todefault to all environments defined in the C1DEFLTS table.

CAUTION:Do not use this utility to initially load the catalog file. Use job BC1JXCNVto load the catalog file. For details, see Step 5: Running the Catalog BuildUtility in this appendix.

B.4.1 Catalog Synchronization Utility JCLTo execute the synchronization utility, use JCL member BC1JCSYN, which isavailable in your site's CA Endevor JCLLIB data set. Edit this member toconform to the needs of your installation before executing the job.



B.4.2 Catalog Synchronization Utility SyntaxTo select which environments the utility will process, you need to edit theBSTIPT DD JCL statement. If the DD statement is omitted or if the file isempty (no input syntax), all environments in the C1DEFLTS table are selected.The BSTIPT file is a 80 character fixed record file. The syntax follows the sameparsing rules as CA Endevor SCL statements.

To select a single environment, specify:

ENVIRONMENT env-name.

To select multiple environments on a single line, specify:

ENVIRONMENT (env-name, env-name, env-name).

To select multiple environments on multiple lines, specify:

ENVIRONMENT (env-name, env-name, env-name,

env-name, env-name).



B.4.3 Catalog Synchronization Utility Sample ReportThe following is a sample report produced by the utility run in validate mode.This execution shows a test CA Endevor system with three environmentsnamed ENV1, ENVA, and ENVZ. In this example, the first two environments,ENV1 and ENVA, are out of synchronization with the catalog.

CA Endevor MCF Catalog Synchronization UTILITY LOG RELEASE 7.� SERIAL B7��C

SYN��I BEGINNING PHASE 1

SYN��2I ENVIRONMENT ENV1 MCF ELEMENT TO CATALOG SYNCRONIZATION STARTING

�MISSING� CTLG SGMT: ELEMENT EJZZBLONGNAME�2

TYPE JDOHFS AT ENV ENV1 SID 1 SYS SYST1�� SBS SBS1��

�MISSING� CTLG SGMT: ELEMENT JBEANlongld5VERYLONGNAMEverylongnameVERYLONGNAMEverylongnameLAROSE


�MISSING� CTLG SGMT: ELEMENT EJudylarose�1


�OLD � CTLG SGMT: ELEMENT EJudylarose�2


�OLD � CTLG SGMT: ELEMENT IA6PGM

TYPE ASMPGM AT ENV ENV1 SID 1 SYS SYST1�� SBS SBS1��

�OLD � CTLG SGMT: ELEMENT OLENIC�1


SYN��3I TOTAL # OF MISSING CTLG SGMTS FROM ENVIRON ENV1 : 3

SYN��4I TOTAL # OF OLD CTLG SGMTS FOUND IN ENVIRON ENV1 : 3

SYN��5I TOTAL # OF ELEMENTS PROCESSED FROM ENVIRON ENV1 : 1�2

SYN��2I ENVIRONMENT ENVA MCF ELEMENT TO CATALOG SYNCRONIZATION STARTING

�MISSING� CTLG SGMT: ELEMENT TESTJO1

TYPE JCLI AT ENV ENVA SID 2 SYS SYSTA�� SBS SBSA��

�MISSING� CTLG SGMT: ELEMENT SANELM1

TYPE JCLI AT ENV ENVA SID 2 SYS SYSTC�� SBS SBSC��

SYN��3I TOTAL # OF MISSING CTLG SGMTS FROM ENVIRON ENVA : 2

SYN��4I TOTAL # OF OLD CTLG SGMTS FOUND IN ENVIRON ENVA : �

SYN��5I TOTAL # OF ELEMENTS PROCESSED FROM ENVIRON ENVA : 5

SYN��2I ENVIRONMENT ENVZ MCF ELEMENT TO CATALOG SYNCRONIZATION STARTING

SYN��3I TOTAL # OF MISSING CTLG SGMTS FROM ENVIRON ENVZ : �

SYN��4I TOTAL # OF OLD CTLG SGMTS FOUND IN ENVIRON ENVZ : �

SYN��5I TOTAL # OF ELEMENTS PROCESSED FROM ENVIRON ENVZ : 1

SYN��11I TOTAL # OF ELEMENTS PROCESSED, ALL ENVIRONMENTS: 1�8


SYN��31I ENVIRONMENT ENV1 CATALOG TO MCF ELEMENT SYNCRONIZATION STARTING.

�ORPHAN � CTLG SGMT: ELEMENT EJudylarose�1


�ORPHAN� CTLG SGMT: ELEMENT EJZZBLONGNAME�2





�ORPHAN � CTLG SGMT: ELEMENT JBEANlongld5VERYLONGNAMEverylongnameVERYLONGNAMEverylongnameLAROSE


SYN��32I TOTAL # OF ORPHAN CTLG SGMTS IN ENVIRON ENV1 : 3

SYN��33I TOTAL CATALOG SEGMENTS PROCESSED FOR ENVIRON ENV1 : 1�5

SYN��31I ENVIRONMENT ENVA CATALOG TO MCF ELEMENT SYNCRONIZATION STARTING.

�ORPHAN � CTLG SGMT: ELEMENT SANELM1


�ORPHAN � CTLG SGMT: ELEMENT TESTJO1


SYN��32I TOTAL # OF ORPHAN CTLG SGMTS IN ENVIRON ENVA : 2

SYN��33I TOTAL CATALOG SEGMENTS PROCESSED FOR ENVIRON ENVA : 7

SYN��31I ENVIRONMENT ENVZ CATALOG TO MCF ELEMENT SYNCRONIZATION STARTING.

SYN��32I TOTAL # OF ORPHAN CTLG SGMTS IN ENVIRON ENVZ : �

SYN��33I TOTAL CATALOG SEGMENTS PROCESSED FOR ENVIRON ENVZ : 1

SYN��34I TOTAL CATALOG SEGMENTS PROCESSED, ALL ENVIRONMENTS: 113



If the utility is executed again, but this time in update mode, the catalog isrepaired and the following log report is produced:




�CREATED� CTLG SGMT: ELEMENT EJZZBLONGNAME�2


�CREATED� CTLG SGMT: ELEMENT JBEANlongld5VERYLONGNAMEverylongnameVERYLONGNAMEverylongnameLAROSE


�CREATED� CTLG SGMT: ELEMENT EJudylarose�1


�UPDATED� CTLG SGMT: ELEMENT EJudylarose�2


�UPDATED� CTLG SGMT: ELEMENT IA6PGM

TYPE ASMPGM AT ENV ENV1 SID 1 SYS SYST1�� SBS SBS1��

�UPDATED� CTLG SGMT: ELEMENT OLENIC�1


SYN��3I TOTAL CATALOG SEGMENTS CREATED FOR ENVIRON ENV1 : 3

SYN��4I TOTAL CATALOG SEGMENTS UPDATED FOR ENVIRON ENV1 : 3

SYN��5I TOTAL # OF ELEMENTS PROCESSED FOR ENVIRON ENV1 : 1�2


�CREATED� CTLG SGMT: ELEMENT TESTJO1


�CREATED� CTLG SGMT: ELEMENT SANELM1


SYN��3I TOTAL CATALOG SEGMENTS CREATED FOR ENVIRON ENVA : 2

SYN��4I TOTAL CATALOG SEGMENTS UPDATED FOR ENVIRON ENVA : �

SYN��5I TOTAL # OF ELEMENTS PROCESSED FOR ENVIRON ENVA : 5


SYN��3I TOTAL CATALOG SEGMENTS CREATED FOR ENVIRON ENVZ : �

SYN��4I TOTAL CATALOG SEGMENTS UPDATED FOR ENVIRON ENVZ : �

SYN��5I TOTAL # OF ELEMENTS PROCESSED FOR ENVIRON ENVZ : 1




�DELETED� CTLG SGMT: ELEMENT EJudylarose�1


�DELETED� CTLG SGMT: ELEMENT EJZZBLONGNAME�2





�DELETED� CTLG SGMT: ELEMENT JBEANlongld5VERYLONGNAMEverylongnameVERYLONGNAMEverylongnameLAROSE


SYN��32I TOTAL CATALOG SEGMENTS DELETED FOR ENVIRON ENV1 : 3



�DELETED� CTLG SGMT: ELEMENT SANELM1


�DELETED� CTLG SGMT: ELEMENT TESTJO1


SYN��32I TOTAL CATALOG SEGMENTS DELETED FOR ENVIRON ENVA : 2



SYN��32I TOTAL CATALOG SEGMENTS DELETED FOR ENVIRON ENVZ : �


SYN��34I TOTAL CATALOG SEGMENTS PROCESSED, ALL ENVIRONMENTS: 113



If the utility is executed a second time in update mode, no discrepancies arefound and the following log report is produced:




SYN��3I TOTAL CATALOG SEGMENTS CREATED FOR ENVIRON ENV1 : �

SYN��4I TOTAL CATALOG SEGMENTS UPDATED FOR ENVIRON ENV1 : �

SYN��5I TOTAL # OF ELEMENTS PROCESSED FOR ENVIRON ENV1 : 1�2


SYN��3I TOTAL CATALOG SEGMENTS CREATED FOR ENVIRON ENVA : �

SYN��4I TOTAL CATALOG SEGMENTS UPDATED FOR ENVIRON ENVA : �

SYN��5I TOTAL # OF ELEMENTS PROCESSED FOR ENVIRON ENVA : 5


SYN��3I TOTAL CATALOG SEGMENTS CREATED FOR ENVIRON ENVZ : �

SYN��4I TOTAL CATALOG SEGMENTS UPDATED FOR ENVIRON ENVZ : �

SYN��5I TOTAL # OF ELEMENTS PROCESSED FOR ENVIRON ENVZ : 1




SYN��32I TOTAL CATALOG SEGMENTS DELETED FOR ENVIRON ENV1 : �



SYN��32I TOTAL CATALOG SEGMENTS DELETED FOR ENVIRON ENVA : �



SYN��32I TOTAL CATALOG SEGMENTS DELETED FOR ENVIRON ENVZ : �


SYN��34I TOTAL CATALOG SEGMENTS PROCESSED, ALL ENVIRONMENTS: 1�8

˚


Appendix C. Interfacing CA Endevor with CACommon Services

With CA Endevor, you can trap messages issued by CA Endevor user exitsand processor programs and display them on the CA Common Services (CCS)Event Console. Once alerted to the event, the Event Console administrator canrespond appropriately.

For example, with this facility you can notify a CA Endevor administratorwhen a CA Endevor package has been denied by one of the package approversor if an attempt to move an element into the production environment fails.

Appendix C. Interfacing CA Endevor with CA Common Services C-1

C.1 Formatting CA Endevor Messages

C.1 Formatting CA Endevor Messages

Lets look at the following message to understand how events issued from CAEndevor can be used by CCS Event Manager. Let's assume this messageappears on the Event Console:

%CATD_I_�6�, SNMPTRAP: -c public 791 172.24.255.255

endevor.machine.name 6 1 ��:��:�� 1 OID:

machine.public.name 6 1 ��:��:�� 1 OID:

1.3.6.1.4.1.791.2.7.3.1

.iso.org.dod.internet.private.enterprises.791.2.7.3.1 VALUE:

ENF�� THIS IS A TEST OF ENDEVOR MESSAGING

The bold portion of the message is the value submitted by user code and thenon-bold part was added by CCS Event Management routines. Let's assumethis message is associated with a rule that looks for the unique trap id,1.3.6.1.4.1.791.2.7.3, of all client-defined CA Endevor messages. When itencounters this message id, it routes the messages to a secondary console thatlogs and prints each message for later review.

It is the responsibility of the CA Endevor administrator to structure thecontents of their messages in a way that allows the message to be trapped andforwarded by CCS Event Manager.

CCS allows a 102-byte message field to be displayed on the Event Console.When you construct a message to be sent to CCS, consider including thefollowing information:

■ A unique message identifier

■ A severity code

■ The date and time

■ CA Endevor inventory location information

■ A detailed description of the error

You should also try to delimit message components with a space or a standardcharacter to simplify forming events and rules.

C-2 Administrator Guide

C.2 How the Interface Works

C.2 How the Interface Works

The following illustration shows how CA Endevor sends messages to the CCSEvent Manager. From CA Endevor, you can code a user exit or a CA Endevorprocessor program and REXX procedure to invoke the CA Endevor Interface,which in turn traps message and sends events to the CCS Event Manager. AnIP address table determines which Event Console receives the event.

The CCS Event Manager takes the free-format 102-byte message and addscontrol and system information before routing the entire message composite tothe indicated consoles. Once the message is received at each console, CCSEvent Management detects messages based upon string content and takesaction using the message action facilities of Event Management.

Refer to the CCS tutorials and documentation for instructions on completingthese tasks.

Procedures for calling the interface from a user exit or from a processor aredescribed next, followed by information about creating the CCS IP addresstable.


C.3 Calling the Interface From a User Exit

C.3 Calling the Interface From a User Exit

One method of calling the CA Endevor Interface is to code a CA Endevor userexit program. The user exit program must call the user exit interfaceassembler program, BC1PTRPO.

The BC1PTRPO user exit interface program requires the following twoparameters:

■ Message — A 102 byte message field which is passed 'as-is' to the EventConsole.

■ Result-area — An 80-byte field into which BC1PTRPO returns the result ofthe Event submission. If the Event submission is successful, it contains"OK" as the first two characters, padded with spaces. Otherwise, itcontains the reason for the Event submission failure.

The user exit must build the message and interrogate the result area. Writinguser exits assumes you have a working knowledge of CA Endevor user exitarchitecture. A sample user exit is delivered as member XIT3MSG, in theiprfx.iqual.SOURCE library. For more information on user exits, see the ExitsGuide.


C.4 Calling the Interface From a Processor


Another way of calling the CA Endevor Interface utilizes a CA Endevorprocessor which executes a REXX procedure. The REXX procedure must callthe REXX procedure interface program, BC1PTRAP.

The BC1PTRAP REXX procedure interface program is an assembler programwhich is called with one parameter and returns a result message to the REXXprocedure. It requires the following parameters:

■ Message — A 102 byte message field which is passed 'as-is' to the EventConsole.

■ Result-area — A field where BC1PTRAP returns the result of the Eventsubmission. If the Event submission is successful, it contains "*-ok" as thefirst four characters, padded with spaces. Otherwise, it contains the reasonfor the Event submission failure.

The REXX procedure must build the message and interrogate the result area.A sample processor and associated REXX procedure are shown next.

C.4.1 Sample CA Endevor Processor FragmentTo call the CA Endevor Interface from a CA Endevor processor, you shouldrefer to the sample processor fragment shown next, in combination with theREXX procedure sample, ENFSAMP, that follows.

//��

//� CREATE TEMPORARY INPUT FILE TO SEND A MESSAGE �

//��

//MSGBLD EXEC PGM=IEBGENER


//SYSUT2 DD

// DSN=BC1USERID..TEMPMSG,DCB=(RECFM=FB,LRECL=8�,BLKSIZE=8��),

// SPACE=(TRK,2,1)

//SYSUT1 DD �

EX 'uprfx.uqual.ISRCLIB(ENFSAMP)' 'ENF�� &C1ACTION &C1ELEMENT'

//SYSIN DD DUMMY

//��

//� SEND A UNICENTER TNG EVENT IN FOREGROUND��

//� NOTE: ATTEMPTING TO RUN THIS STEP IN BG��

//� WILL RESULT IN RC=5��

//��

//SMSGFG EXEC PGM=BC1PTMP�,MAXRC=5,

// PARM='BC1USERID..TEMPMSG'

//STEPLIB DD DSN=uprfx.uqual.AUTHLIB,DISP=SHR

// DD DSN=iprfx.iqual.CONLIB,DISP=SHR

//SYSTERM DD DSN=&&PARMLIST,DISP=(OLD,PASS)

//SYSTSPRT DD DSN=&&PARMLIST,DISP=(OLD,PASS)

//SYSPRINT DD DSN=&&PARMLIST,DISP=(OLD,PASS)

//SYSOUT DD DSN=&&PARMLIST,DISP=(OLD,PASS)



//��

//� SEND A UNICENTER TNG EVENT IN BACKGROUND �

//��

//SMSGBG EXEC PGM=IKJEFT�1,

// COND=((5,NE,SMSGFG),(5,LT)),MAXRC=7

//SYSTSPRT DD DSN=&&PARMLIST,DISP=(OLD,PASS)

//SYSTSIN DD DSN=&&TEMPMSG,DISP=OLD

C.4.2 REXX Procedure SampleThe REXX procedure, ENFSAMP, passes a message to the CA Endevor REXXinterface program, BC1PTRAP. Any error conditions are passed back to theREXX procedure using standard REXX WORD return protocol.

The following REXX procedure corresponds to the previous processorfragment:

/� REXX �/

ARG child_prm

msgid = WORD(child_prm,1)

prm1 = WORD(child_prm,2)

prm2 = WORD(child_prm,3)

"ISPEXEC LIBDEF ISPLLIB DATASET ID('iprfx.iqual.CONLIB')"

/�Note� The length of a REXX generated message �/

/�Note� must be 2 bytes less than the maximum �/

/�Note� 1�4 to account for the enclosing quotes�/

message= msgid||" A "||prm1||" OF "||prm2||" FAILED"

message=LEFT(message,1�2)

y=BC1PTRAP(message)

IF WORD(y,1)/="�-ok" THEN

DO

SAY "Return from BC1TRAP� is "||WORD(y,1)

SAY "Reason is "||WORD(y,2)

END

ELSE

SAY "Message successfully sent"

"ISPEXEC LIBDEF ISPLLIB"

EXIT


C.5 Setting Up the IP Addresses of Event Consoles


Once the CA Endevor Interface receives the message events from either theuser exit or CA Endevor processor, it needs to know where to direct theevents. The BC1TIPAD macro is used to specify the IP addresses of EventConsoles. There are three types of BC1TIPAD macros, which are distinguishedby the keyword parameter IPVAL:

■ IPVAL=START is required as the first macro. It indicates the beginning ofthe table.

■ IPVAL=IP address identifies the address of an Event Console to which themessages are routed. You can code as many of these parameters as youneed; at least one is required.

■ IPVAL=END is required as the last macro. It indicates the end of thetable.

JCL to assemble and link-edit this table is located as member BC1JIPAD in theiprfx.iqual.JCLLIB library. This member contains an embedded BC1TIPADmacro source. After editing the IP address macros, copy your JOBCARDmember to the beginning of BC1JIPAD, and then submit the job for execution.

The file containing the BC1JIPAD member delivered on the installation tape isshown next. Step 1 assembles the macro and passes the assembled IP addresstable to Step 2. Step 2 link-edits the IP address table, then stores it in theAUTHLIB as member BC1TIPAD.

/�(JOBCARD)

//�-----------------------------------------------------------------�

//� �

//� ENDEVOR IP ADDRESS TABLE. USED TO IDENTIFY EACH OF THE �

//� UNICENTER TNG CONSOLE IP ADDRESSES. THE ENDEVOR INTERFACE �

//� MESSAGING FACILITY WILL ROUTE MESSAGES TO EACH OF THE IP �

//� ADDRESSES DEFINED IN THE BC1TIPAD TABLE. �

//�-----------------------------------------------------------------�

//� STEP 1: ASSEMBLE THE ENDEVOR IP ADDRESS TABLE �

//�-----------------------------------------------------------------�

//ASM EXEC PGM=ASMA9�,REGION=4�96K,




// UNIT=tdisk,

// SPACE=(TRK,(3,5)),




//SYSPUNCH DD DUMMY


//SYSIN DD �

�----------------------------------------------------------�

� NAME: BC1TIPAD �



� �

� FUNCTION: ENDEVOR IP ADDRESS TABLE. USED TO �

� IDENTIFY EACH OF THE UNICENTER TNG CONSOLE IP ADDRESSES. �

� THE ENDEVOR INTERFACE MESSAGING FACILITY WILL ROUTE �

� A MESSAGE TO EACH OF THE IP ADDRESSES DEFINED IN �

� THIS TABLE. �

� �

�----------------------------------------------------------�

@IPADDR IPVAL=START

�

@IPADDR IPVAL=174.24.255.1

@IPADDR IPVAL=174.24.255.2

�

@IPADDR IPVAL=END

/�

//�-------------------- -----------------------------------�

//� STEP 2: LINK EDIT THE BC1TIPAD IP ADDRESS TABLE �

//�--------------------------------------------------------�

//LINK EXEC PGM=IEWL,REGION=2�48K,COND=(�,NE),

// PARM='LIST,NCAL,XREF,LET,RENT,REUS'



//SYSLMOD DD DISP=SHR,DSN=uprfx.uqual.AUTHLIBHLIB(BC1TIPAD)




Appendix D. Long Name and HFS File Support

This appendix contains the following sections:

■ Long name and HFS support overview

■ Long name elements

■ HFS files and directories

■ HFS RECFM field in Type Definition panel

Appendix D. Long Name and HFS File Support D-1

D.1 Long Name and HFS Support Overview


Long name support allows CA Endevor to support the following:

■ Case-sensitive element names for files added from Hierarchical File System(HFS) volumes

■ HFS path and file information in batch add, update, and retrieve actions

■ HFS directories as base, source output, and include libraries on typedefinitions

■ Processor symbolics for long name elements and HFS directories

■ HFS path and file name support for the CONWRITE and CONDELEutilities

D.1.1 HFS Path NameThe HFS path name can be a maximum of 768 characters long and contain thefollowing characters:

■ Uppercase letters

■ Lowercase letters

■ Numbers

■ National characters

■ Slash (/)

■ Plus (+)

■ Hyphen (-)

■ Period (.)

D.1.2 HFS FilesA file name can be 255 characters long. To be portable, the file name shoulduse only the characters in the POSIX portable file name character set, describednext:

■ Uppercase or lowercase A to Z

■ Numbers 0 to 9

■ Period (.)

■ Underscore (_)

■ Hyphen (-)

Following are the rules for naming a file:

■ The file name cannot contain null or / (slash) character.

D-2 Administrator Guide


■ The file name does not support double- byte characters.

■ Shells are case-sensitive, so distinguish between upper and lower casecharacters. For example, FILE1 and file1 are not the same file names.

■ The file name can include the following:

– Suffixes

– An extension, consisting of a period (.) and several characters, toindicate its file type. Files containing C code could have the extension.c, for example:

dbmod3.c

Using suffixes and extensions to group like files together is stronglyrecommended, it allows you to execute a single command against multiplefiles.

Warning: Double-byte characters in a file name can cause problems, they aretreated as single-byte data. If one of the double-byte characters is a period (.)or / (slash), the file system treats these as path name delimiters.

D.1.3 Element NamesElement names can be 255 characters long, containing the following characters:

■ Uppercase letters

■ Lowercase letters

■ Numbers

■ National characters

■ Period(.)

■ Hyphen (-)

■ Underscore(_)



D.1.4 Long Name Support and CA Endevor InterfacesLong name support varies for the CA Endevor interfaces. The following tableexplains these differences:

Interface Long Name and HFS support

ISPF

Quick Edit

No support for actions involving long name elements or pathnames.

Element names greater than 10 characters are truncated inlists. The truncated format consists of:

■ A left brace ({)■ The first five characters of the element name■ An ellipsis (...)■ A right brace (})

For example, element 'longnameelement' displays in ISPF as:

{longn...}

Note: Element information is not available from the ISPF list,it is only accessible from the Enterprise Workbench. Ifthere are multiple long name elements and the firstfive characters are identical, ISPF displays a singleentry.

HFS path names longer than 44 characters are truncated intype definitions and on the element master display screen.The truncated format consists of:

■ Left bracket ({)■ The first 39 characters of the path name■ An ellipsis (...)■ Right bracket (})

Batch (SCL)

API

EnterpriseWorkbench

■ Element names can be 255 characters long, containingmixed-case

■ Periods, underscores, and hyphens are valid characters■ Path names can be 768 characters, not including the HFS

file name



Notes:

HFS path and file name support is unavailable for the following functions:

1. CONLIST, CONRELE, or other utilities

2. The processor keyword MONITOR=

3. The processor keyword FOOTPRNT

4. Package Backout

5. Package Ship


D.2 Long Name Elements


This section provides information about how long name elements are added,stored, and displayed in CA Endevor.

D.2.1 Adding and Retrieving Long Name ElementsThese "file types" are used to add elements to CA Endevor or retrieve elementsfrom CA Endevor:

■ DSN files — CA Endevor supports base and source output libraries:

– PDS/PDSE

– ELIB

– AllFusion CA-Panvalet

– AllFusion CA-Librarian

■ HFS path and file names

Elements can be retrieved from CA Endevor and saved as a DSN member oras a file in the HFS directory. There is no relationship between the elementname and the member name/file name. The element name's characteristicslimit which file type can be used as the target of the retrieve action, as shownin the following table:

Element NameCharacteristics

HFS DSN

Long �1�— alphanumeric,mixed case and @, $, #, ., -, _

Yes No

Short �2�— alphanumeric,mixed case and @, $, #, ., -, _

Yes No

Short �2�— alphanumeric,upper case and @, $, #

Yes Yes

Note: �1�: Names are greater than 10 and less than 256 characters�2�: Names are less than or equal to 10 characters



D.2.2 Storing Long Name ElementsThe following table summarizes the supported storage definitions and anylimitations for elements in CA Endevor:


HFSBase

DSNBase

HFSSourceOutput

DSNSourceOutput


Yes Forward-deltaonly

Yes No


Yes Forward-deltaonly

Yes No


Yes Yes Yes Yes

Note: �1�: Names are greater than 10 and less than 256 characters�2�: Names are less than or equal to 10 characters

D.2.3 Displaying Element InformationElement lists behave differently in the various interfaces. ISPF and Quick Editlists use brackets to designate long name elements and short name elementswith lower case characters. Enterprise Workbench displays the full elementname. The following table explains these differences:


Sample ElementName

ISPF/Quick Edit EnterpriseWorkbench


abcdefghijklm {abcde...} �3� abcdefghijklm


LoNgNaMe {LoNgNaMe} �3� LoNgNaMe


ELEMENT1 ELEMENT1 ELEMENT1

Note:

�1�: Names are greater than 10 and less than 256 characters�2�: Names are less than or equal to 10 characters

�3�: Element information is not available from these lists, it is only accessible from the EnterpriseWorkbench. If there are multiple long name elements and the first five characters are identical, ISPFdisplays a single entry.


D.3 HFS Files and Directories


This section provides information about HFS files and directories.

D.3.1 HFS Directories and CA Endevor LibrariesWith UNIX System Services (USS) HFS File support some CA Endevorlibraries can be located in HFS partitions. Currently, the only supportedlibraries are:

■ Base

■ Source output

■ Include

The following table lists the CA Endevor libraries that can be located in HFSpartitions:

Notes:

1. Processors can write outputs to HFS directories.

2. Ensure that the maximum record size associated with the HFS file can beaccommodated by the delta library specified on the type definition.

Library z/OS HFS

Master Control Files Yes No

Package data set Yes No

Base libraries Yes Yes

Delta libraries Yes No

Processor output libraries Yes No

Source output libraries Yes Yes

Processor load libraries Yes No

Processor listing libraries Yes No

CA Endevor listing libraries Yes No

Include libraries Yes Yes



D.3.2 Using Site Symbolics for Type DefinitionsWhen designating HFS directories as base, source output, or include librariesin type definitions, you must use site symbolics. When viewing the typedefinition in ISPF, symbolics are displayed for the longer paths. As with CAEndevor or user symbolics, the site symbolics are resolved at runtime.



D.3.3 HFS Directories and CA Endevor ActionsCA Endevor supports HFS directories for add/update and retrieve actionsinitiated in batch (SCL) or from Enterprise Workbench. The following tablesummarizes the actions supported by HFS locations:

Action Fields HFS Support

Add/Update 'from' Y

Retrieve 'to' Y

Archive 'to' N

Restore 'from' N

Transfer 'from archive' and'to archive'

N

Unload 'to' N

Reload 'from' N

D.3.4 HFS Files and CA Endevor ActionsCA Endevor allows you to work with HFS files, long name elements and shortnames containing lower case characters using the Enterprise Workbench or thebatch interface. The following table summarizes the supported actions:

Action Enterprise Workbench ISPF Quick Edit Batch SCL

Master display,Element name

Displays full name N/A {abcde...}

Master display,'Retrieved to'

Displays full path N/A Brackets if > 44characters

Master display,'Added from'

Displays full path N/A Brackets if > 44characters

Add\Update,'Add from'

Input allowed Input not allowed Full HFS path and filename

Retrieve,'Retrieve to'

Input allowed Input not allowed Full HFS path and filename

Type definitionBase librariesSource output librariesInclude libraries

Input allowed Input not allowed Using site symbolics

Type display Displays full path Displays symbolics N/A

Note: N/A - Not applicable


D.4 HFS RECFM Field in Type Definition Panel

D.4 HFS RECFM Field in Type Definition Panel

Listed next is information on the HFS RECFM field. This field is located on theType Definition panel, shown next:


COMMAND ===>




UPDATED: BY

----------------- ELEMENT OPTIONS -------------------

FWD/REV/IMG DELTA ===> R (F/R/I) COMPRESS BASE/ENCRYPT NAME ===> Y (Y/N)

DFLT PROC GRP ===> CLENBL REGRESSION PCT ===> 75 REGR SEV ===> W (I/W/C/E)

SOURCE LENGTH ===> 8� COMPARE FROM ===> 7 COMPARE TO ===> 72

AUTO CONSOL ===> Y (Y/N) LANGUAGE ===> cobol PV/LB LANG ===> DATA

CONSOL AT LVL ===> 96 HFS RECFM ===> NL (COMP/CR/CRLF/F/LF/NL/V)LVLS TO CONSOL ===> 49 DATA FORMAT ===> B FILE EXT ===>




--------------------- LIBRARIES ---------------------

BASE/IMAGE LIBRARY ===> CA.ENDEVOR.SMPL&C1ST..BASE

DELTA LIBRARY ===> CA.ENDEVOR.SMPL&C1ST..DELTA

INCLUDE LIBRARY ===>

SOURCE O/P LIBRARY ===>

EXPAND INCLUDES ===> N (Y/N)

� �

Parameters

HFS RECFMUSS/HFS files are data streams. The HFS RECFM field specifies a recorddelimiter used to emulate records. To emulate records, there must be arecord delimiter. This is the purpose of the HFS RECFM field. Recorddelimiters and their HFS delimiter type are as follows:

■ COMP — Variable length records compressed by CA Endevor■ CR — Carriage return (ASCII & EBCDIC "CR" is hex '0D)■ CRLF — EBCDIC Carriage return/line feed (hex '0D25')■ F —Fixed length■ LF — EBCDIC line feed (hex '25')■ NL — EBCDIC new line character. This is the delimiter used by the

editor, OEDIT and OBROWSE. This is the default.■ V — Variable. The first two bytes of the record are the RDW (record

descriptor word) and it contains the length of the record including theRDW.

Note: The maximum record length is 32000 bytes.


Appendix E. Working with Binary Files

To define an element type for binary files (for example, WAR, EAR, JAR DOC,PPT, XLS), follow the following steps:

1. Define the Base library— The base library must be an HFS file.

2. Define the Delta library— Define the delta library with the followingconsiderations in mind:

■ The delta PDS record format must be variable blocked.

■ The delta library record length and the type definition source lengthcan be any value (259, 6024, 27984) as long as the maximum deltarecord length is about 2 times the source length. However, a value of27,984 is recommended.

For example,

DCB=(DSORG=PO,RECFM=VB,LRECL=27984,BLKSIZE=�)

3. Type definition—Define the binary element type to include the followingelement options:

■ Set the Fwd/Rev/Img Delta field to I. The delta type should be fullimage. This suppresses the compare logic. Each update will cause theentire file to be added as a new level.

■ Set the Compare From field to a value of 1.

■ Set the Source Length field and the Compare To field to a value of13,992.

■ Set the HFS RECFM field to F.

■ Set the Data Format field to B, for binary. If left blank, the valuedefaults to B.

■ Set the File Ext field to a valid file extention type (doc, ppt, xls, jar, ear,and so on) or leave it blank. The file extension identifies the file typewhen you are adding from or retrieving to a local file directory usingCA CM Enterprise Workbench.

Appendix E. Working with Binary Files E-1

For example, the following sample Type Definition panel shows how youcan define a DOC file type:

� � DISPLAY ---------------------- TYPE DEFINITION ---------------------

COMMAND ===>

CURRENT ENV: I4� STAGE ID: 1 SYSTEM: NDVRMVS TYPE: HFSFB

NEXT ENV: I4� STAGE ID: 2 SYSTEM: NDVRMVS TYPE: HFSFB

DESCRIPTION: Binary Data with delta lrecl of 13,992

UPDATED: 29MAR�4 11:47 BY XAHFS�1

----------------- ELEMENT OPTIONS -------------------

FWD/REV/IMG DELTA: I (F/R/I) COMPRESS BASE/ENCRYPT NAME: Y (Y/N)

DFLT PROC GRP: �NOPROC� REGRESSION PCT: �� REGR SEV: C

(I/W/C/E)

SOURCE LENGTH: 13992 COMPARE FROM: 1 COMPARE TO: 13992

AUTO CONSOL: Y (Y/N) LANGUAGE: DATA PV/LB LANG: DAT

CONSOL AT LVL: 96 HFS RECFM: F (COMP/CR/CRLF/F/LF/NL/V)

LVLS TO CONSOL: 5� DATA FORMAT: B FILE EXT: doc


FWD/REV DELTA: F (F/R) AUTO CONSOL: Y (Y/N) CONSOL AT LVL: 96

LVLS TO CONSOL: 5�

-------------------- LIBRARIES ---------------------

BASE/IMAGE LIBRARY: &#HFS8�I1

DELTA LIBRARY: BST.HFSVB.DELTA

INCLUDE LIBRARY:

SOURCE O/P LIBRARY:

� �

E-2 Administrator Guide

Appendix F. Email Notification

This appendix describes Email Notification facility.

Email notification within CA Endevor is enabled by creating the mainframe IDand email ID table, ESMTPTBL. This table maps mainframe user IDs to emailIDs or group names. When an email notification event occurs, the invokedprogram scans the ESMTPTBL table for an appropriate match. The programsearches the table for a matching mainframe ID. If a match is found, an emailaddressed to the associated email ID is sent. If no match is found, no email issent.

However, if you code the DFTID=USERID parameter in the ESMTPTBL,instead of bypassing unlisted IDs, CA Endevor will construct an email addresswith the CA Endevor user ID suffixed with the default domain. If your sitehas defined email aliases for all your mainframe user IDs, coding ofDFTID=USERID allows you to reduce the size of the ESMTPTBL and makes iteasier to maintain.

The email interface utility BC1PMLIF allows you to write simple emailprograms without having an in-depth knowledge of the NOTIFY block or theESMTP table lookup. For details about BC1PMLIF, see Email Interface ProgramBC1PMLIF in the chapter “Notification Utility” in the Utilities Guide. For asample COBOL email program that uses the BC1PMLIF interface, see thesample program CALLMLIF in Notification Utility Exit Programs in thechapter “Exit Program Examples” in the Exits Guide.

Appendix F. Email Notification F-1

F.1 Email Notification Components

F.1 Email Notification Components

The following components are provided as part of the Email NotificationFacility:

Component Description

$ESMTP Macro that builds a table (ESMTPTBL) that maps mainframe IDs to emailIDs.

ESMTPTBL Table created by the macro $ESMTP to map mainframe IDs to email IDs.

BC1JSMTP JCL used to assemble and link the ESMTPTBL table.

F-2 Administrator Guide

F.2 $ESMTP Macro

F.2 $ESMTP Macro

The macro, $ESMTP, builds the mainframe ID and email ID table, ESMTPTBL.The macro has a section for global information and a section for eachmainframe user ID.

The JCL to assemble and link this macro is located in iprfx.iqual.jcllib. Theresulting load module, ESMTPTBL, must reside in the CA Endevor authorizedlibrary (uprfx.uqual or iprfx.iqual.AUTHLIB).

The global information section includes the following fields:

Item Description

ATSIGN Use this field to specify the byte value that replaces the @ sign in emailaddresses. You can specify any value, except 00 and 40. For example,ATSIGN=80. The default value is 7C.

HOSTNAME NJE node name of the OS/390 system where SMTP is running.

DFTDOMAIN Domain name to be used in email addresses. You can override this field inthe mainframe ID section.

DFTURL URL where Enterprise Workbench is running. You can override this fieldin the mainframe ID section.

DFTID=USERID If CA Endevor cannot find the USERID in ESMTPTBL and DFTID=USERIDis coded, CA Endevor attempts to send an email to the mainframe user IDby constructing an email address with the CA Endevor user ID suffixedwith the default domain. Without DTFID=USERID, CA Endevor does notsend an email if it cannot find the mainframe user ID in ESMTPTBL. Thisparameter does not override email addresses in ESMTPTBL. If an invalidaddress is found in ESMTPTBL, no email is sent to that user ID.

To enable the default ID feature, only one value is permitted(DFTID=USERID). If the value is omitted, or coded as null (DFTID=), thenthe parameter has no effect.

SMTPTASKNAME The name of the SMTP address space. The default is SMTP and is rarelysubject to change.

SMTPCLASS The SYSOUT CLASS associated with the SMTP task. The default is B andis rarely subject to change.

The mainframe ID/email ID section includes the following fields:

Item Description

HOSTNAME NJE node name of the OS/390 system where SMTP is running.


F.2 $ESMTP Macro

Item Description

MFID The mainframe user ID or package approver group name. This field cancontain up to 16 character.

EMAILID The portion of the email ID that preceeds the @. This field size isunlimited.

DOMAIN The portion of the email ID that follows the @. If not specified, the globaldefault domain is used. This parameter supports an environment whereemail IDs might be defined in multiple domains.

URL The URL where Enterprise Workbench is running. If not specified, theglobal default URL is used. This parameter enables you to point users todifferent implementations of Enterprise Workbench.

Disable Notification for Specific Users: To completely disable notificationsfor a particular user, simply provide a dummy or invalid email address. Thedefault does not override any explicitly coded email address; therefore, if youleave an invalid email address in ESMTPTBL, no email is actually delivered tothat particular user.


F.3 Sample ESMTPTBL

F.3 Sample ESMTPTBL

A sample ESMTPTBL table, shown next, is provided in the Source library:

Col

72

��

� FIRST INVOCATION - DEFINE "GLOBAL" VALUES

�---------------------------------------------------------------------�

$ESMTP HOSTNAME=USILDAMA, X

DFTDOMAIN=ca.com,ATSIGN=7C, X

DFTURL='http://endevor�/ccm1��2/webpages/login.jsp' X

DFTID=USRID --> send EMAIL to undefined user- IDs.

��

� SUBSEQUENT INVOCATIONS - DEFINE APPROVER GROUP NAME OR USERIDS

�---------------------------------------------------------------------�

$ESMTP MFID=APPRV�1,EMAILID=Approver1


$ESMTP MFID=APPRV�3,EMAILID=Approver3, X

DOMAIN=cai.com,url='http://www.my.yahoo.com'




$ESMTP MFID=PGH-MIM,EMAILID=PGH.MIM

��

� LAST INVOCATION - END THE TABLE GENERATION

�---------------------------------------------------------------------�

$ESMTP CALL=END

The sample ESMTPTBL includes the DFTID=USERID parameter, which enablesCA Endevor to construct email addresses from the CA Endevor user ID andthe default domain. If your ESMTPTBL includes DFTID=USERID, when apackage is cast requiring an approval from one or more users not defined inthe table, for example peter01 and sally02, CA Endevor will send an email [email protected] and [email protected], in addition to emails to usersdefined in the table.


F.4 BC1JSMTP

F.4 BC1JSMTP

The sample BC1JSMTP JCL shown next, which can be used to assemble andlink ESMTPTBL, is provided in the JCL library (iprfx.iqual.JCLLIB):

//�(JOBCARD)

//�-------------------------------------------------------------------�

//� �

//� �

//� NAME: BC1JSMTP �

//� �

//� PURPOSE: BC1JSMTP IS USED TO ASSEMBLE AND LINK EDIT THE �

//� ENDEVOR-USERID / EMAIL-ID EQUIVALENCE TABLE �

//� �

//� �

//�-------------------------------------------------------------------�

//� STEP 1: ASSEMBLE THE ENDEVOR EMAIL MAINFRAME ID / EMAIL ID TABLE �

//�-------------------------------------------------------------------�


// REGION=3�72K,


//SYSLIB DD DISP=SHR,DSN=IPRFX.IQUAL.SOURCE


// UNIT=TDISK,

// SPACE=(TRK,(3,5)),



//SYSPUNCH DD DUMMY

//SYSUT1 DD UNIT=TDISK,SPACE=(TRK,(5,15))


//SYSIN DD DISP=SHR,DSN=IPRFX.IQUAL.SOURCE(ESMTPTBL)

//�-------------------------------------------------------------------�

//� STEP 2: LINK EDIT THE TABLE. �

//� THE SYSLMOD DD STATEMENT DEFINES THE LIBRARY FOR ESMTPTBL. THIS �

//� STEP PLACES THE ESMTPTBL LOAD MODULE INTO THE USER AUTHLIB DATA �

//� SET. �

//�-------------------------------------------------------------------�


// REGION=2�48K,

// PARM='LIST,NCAL,XREF,LET,RENT,REUS',

// COND=(�,NE)




//SYSLMOD DD DISP=SHR,DSN=UPRFX.UQUAL.AUTHLIB(ESMTPTBL)

//SYSUT1 DD UNIT=TDISK,SPACE=(TRK,(5,15))


Index

Special Characters$CIPOREC 8-14$SMFBKDS 9-13$SMFHDDS 9-5$SMFREC1 9-7$SMFREC2 9-11++CONTROL password interface 6-13

AAction

availability 1-18blocks 9-3by job function 1-19Display 1-18Prompt panel 8-4

Action Recordsblocks 9-4, 9-11, 9-13SMF 9-3

Add ActionCCIDs updates 8-5function 1-18specifying for elements 8-6

Adding options to User Options Menu 11-4Addresses IP C-7Adjusting type definitions A-4AllFusion CA-Librarian 15-7AllFusion CA-Panvalet 15-7AllFusion CA-Panvalet Interface

access module, link-editing 6-11setting parameters 6-12

Allocating base libraries A-3Alternate Defaults Table

creating 14-5example 14-6

Alternate ID support 6-22Analyzing types for deltas A-2Archive Action 1-18

AttributesLOG 15-11tuning 15-14

Audit stamps 1-21

BBase libraries

about 1-15allocating A-3resizing A-3symbolics 3-44

Base members 15-6BC1JRELD A-4BC1JUNLD A-3BC1JVALD A-5BC1PNCPY 15-8BC1PTRAP REXX procedure C-5BC1PTRPO C-4Blocks

about 9-2action-specific 9-13

Buffer pool 15-10

CC1DEFLT macros 4-3C1DEFLTs

adding the element catalog B-3CA Common Services Event Manager (CCS) C-2CA Endevor

Actions 1-18calling the Interface C-4ESI 1-22inventory structure

classifying elements 1-13setting up 1-7

library list 1-15messages C-3security 1-22

Index X-1

CA-AllFusion CA-Librarian Interfacecustomizing 6-17defining Endevor types 6-20setting parameters 6-16

CA-L-Serv 15-9Calling the CA Endevor interface C-4Capturing elements A-3CCID definition data set

adding to Defaults Table 6-8allocating 6-7initializing 6-8installation steps 6-7setting parameters 6-9

CCIDsabout 8-1Add Action updates 8-5data set sample definition 8-15definition data set 8-13, 8-14Delete Action updates 8-9Endevor's impact on actions 8-10fields 8-2Generate Action updates 8-7ISPF Text Editor 8-14Move Action updates 8-8predefining 8-12requiring 8-3Restore Action updates 8-10Retrieve Action updates 8-7sample definition 8-15Transfer Action updates 8-8updating fields 8-5validation 8-12

Change Control Identifiers see CCIDsChanging name of data set for a system 3-50Classifications for Inventory maps 4-3Classifying elements 1-13Cloning 3-26Commands 1-18Comments see CCIDsCommunication Server 15-10Components of logical structure 1-6Consolidation trigger level 15-4Conventions for naming types 3-42Converging

routes 4-6systems in a route 4-7

Conversioncatalog build B-3MCF B-2package data sets B-2

Conversionsdeltas A-2, A-6forward/reverse to full-image A-7

CONWRITE utilityabout 15-2modifying processors A-3tuning processors 15-13

Copy Action 1-18Copyback 8-7Copying system, subsystems and types 3-26Creating

CCID definition data set 8-13executable forms of elements 1-20

Cycle, software life 1-3

DData

setssecurity 1-22

Data blocksabout 9-2security 9-7

Data setsCCIDs definition 8-13definitions for type 3-50field definition 8-15package 1-15sample definition 8-15Type panel 3-51Type Request panel 3-50

Defaults Tableabout 1-2assembling 13-5editing 13-4establishing routes 4-3

Definingenvironments 1-8maps 4-3new systems 3-18processing sequence 3-46subsystems 1-11, 3-29symbolics 3-44systems 1-10, 3-18types 1-12, 3-32, 3-46

Definition file 8-13Delete

processors 1-20Delete Action

CCIDs updates 8-9function 1-18

X-2 Administrator Guide

Deltasanalyzing types A-2consolidation trigger level 15-4conversions A-2, A-7element consolidation 15-4formats 15-2forward 3-44full-image 3-44libraries 1-15library types 15-6number of levels to retain 15-4resizing libraries A-3reverse 3-43storage formats 3-42symbolics 3-44

Displayenvironment information 3-53Site Information panel 3-7Stage Information panel 3-16

DSECTs$SMFBKDS 9-13$SMFHDDS 9-5$SMFREC1 9-7$SMFREC2 9-11about 9-5SMF security records 9-2

Duplicate element namesprocessor group 5-5subsystem level 5-2system level 5-2

duplicate elements 5-1Duplicating system, subsystems and types 3-26

EEditor 8-14Element Catalog 1-15

build B-3building B-2C1DEFLTs B-3MCF conversion B-2

Element Registration 5-1—5-7Elements

capturing A-3classifying 1-13creating executable forms 1-20definition of 1-7delta consolidation 15-4querying for 1-14specifying an Add Action 8-6storage formats 3-42

Elements (continued)unload A-3working with 1-18

Email notificationESMTPTBL F-1

ENCOPTBLEndevor

definition data set 8-13impact on fields 8-10LIB 15-6security 9-1updating CCIDs fields 8-5

ENFSAMP C-5ENUXSITE 14-1

See also Alternate Defaults TableEnvironment

defining 1-8definition of 1-6displaying information 3-53Information panel 3-53mapping 15-5options menu 3-4

ESI 1-22Establishing routes in the Defaults Table 4-3Evaluating processors A-3Event Manager for C-2Event Manager for CA Common Services

(CCS) C-2Execute

BC1JRELD A-4BC1JVALD A-5forms of elements 1-20

Exit program for CA Endevor users C-4External Security Interface (CA Endevor ESI) 1-22

FFacility native security 1-22Fields

$SMFHDDS DSECT 9-6$SMFREC1 DSECT 9-8$SMFREC2 DSECT 9-12action block 9-16—9-20CCIDs 8-2definition data set 8-15Endevor actions impact on 8-10Environment Information panel 3-53Site Information panel 3-8Stage Information panel 3-16Subsystem Definition 3-30System Definition panel 3-20

Index X-3

Fields (continued)System Definition panel for cloning 3-27Type Definition panel 3-35Type Processing Sequence panel 3-48updating CCIDs 8-5

File definition 8-13File processing for VSAM 15-9Footprints 1-21Formats for deltas 15-2Formatting messages C-2Forward deltas

about 3-44, 15-2conversion to full-image A-7conversion to reverse A-2

Full-image deltasabout 3-44, 15-2conversion from forward/reverse A-7

Functionsfor jobs 1-19for menus 11-2

GGenerate

processors 1-20Generate Action


GLobal Type Sequencing 6-27

HHeader blocks

about 9-2SMF 9-5

HistoryMove Action 8-8Transfer Action 8-8WITH option for deltas A-7

IIdentifying systems 3-5Impact of Endevor on fields 8-10Implementing Record Level Sharing 15-12Include libraries 1-17Interfaces

++CONTROL password interface 6-13AllFusion CA-Panvalet Interface 6-11CA-AllFusion CA-Librarian Interface 6-16SMF interface 6-9

Inventory map classifications 4-3Inventory structure

classifying elements 1-13components 1-6querying 1-14setting up 1-7

IP addresses C-7IPVAL C-7ISPF

panels 11-5Text Editor 8-14

ISPF dialog options configuration tableassembling and link-editing 12-13default configuration table 12-3dialog options fields 12-5overview 12-1

LLevels number of to retain 15-4LIB 15-6Libraries

about 1-15Base

allocating A-3resizing A-3symbolics 3-44

Deltasresizing A-3types 15-6

include 1-17list 1-15types 15-6

Life cycle of software 1-3List Action 1-18Listing libraries 1-17LOG attributes 15-11Logical structure

classifying elements 1-13components 1-6querying 1-14setting up 1-7

MMacros

$CIPOREC 8-14for BC1TIPAD C-7

Managing actions 1-20Mapping multiple environments 15-5


Maps 4-1—4-5Master Control File (MCF)

CA-L-Serv 15-9definition of 1-15

MCF Catalogconvert B-2defining B-3rename utility B-7update B-7utility B-7validate B-7

Menusenvironment options 3-4functions 11-2modifying User Options 11-4User Option 11-2

Messages formatting C-2Modifying

processors A-3User Options Menu 11-4

Monitoring CA-L-Serv's performance 15-9Move

processors 1-20Move Action

CCIDs updates 8-8function 1-18with history 8-8without history 8-8

Multiple mapping environments 15-5

NNaming conventions 3-42Native security facility 1-22New systems defining 3-18Number of levels to retain 15-4

OOptional feature table

activating source entries 6-2ENCOPTBL 6-2source 6-2

Optionsenvironment menu 3-4User Menu 11-2

Outputlibraries 1-17management 1-20

Output Typeelement registration 5-7

PPackage data set 1-15Package data sets

conversion B-2Packages 1-21Panels

about 3-2Action Prompt 8-4Environment Information 3-53ISPF 11-5Request 3-5Selection List 3-5Site Information 3-7Stage Information 3-16Subsystem

Definition 3-30Request 3-29

SystemDefinition 3-19, 3-27Request 3-18

TypeData Set Request 3-50Data Sets 3-51Definition 3-34Processing Sequence 3-47Request 3-32Sequence Request 3-46

User Options Menu 11-3using to define a map 4-3

Parametersconsolidation trigger level 15-4for BC1PTRAP C-5for BC1PTRPO C-4IPVAL C-7number of levels to consolidate 15-4RECBUFFSIZE 15-9

Parmlib data set 6-26Partitioned data set (PDS) 1-7Password

++CONTROL password interface 6-13PDS 1-7, 15-6PDS/E 15-6Point in Time Recovery 15-9Predefining CCIDs 8-12Print Action 1-19Procedure

adding options to User Options Menu 11-4BC1PTRAP REXX C-5changing name of data set for a system 3-50cloning inventory definitions 3-26

Index X-5

Procedure (continued)converting forward to reverse delta A-2creating CCID definition data set 8-13defining

new system 3-18subsystem 3-29type processing sequence 3-46types 3-33

removing options from User Options Menu 11-4requiring CCIDs for a system 8-3

Processingbackout 15-2sequence 3-46

Processor Groupduplicate elements 5-5element registration 5-5, 5-7output type 5-7

Processorscalling CA Endevor Interface C-5evaluating A-3libraries 1-15modifying A-3tuning 15-13types of 1-20

ProgramsBC1PTRAP C-5BC1PTRPO C-4user exit C-4

Providing stage id 4-3

QQuerying the inventory structure 1-14

RRECBUFFSIZE 15-9Record level sharing (RLS) 15-11Records

data block security 9-7SMF 9-2

Recovery Point in Time 15-9Reload utility A-4Removing options from User Options Menu 11-4Reporting 1-20Request panel 3-5Requiring CCIDs for a system 8-3Resizing base libraries A-3Restore Action


Retain number of levels to 15-4Retrieve Action


Reverse deltasabout 3-43, 15-2conversion from forward A-2, A-6conversion to full-image A-7

REXX procedure C-5RLS 15-11Routes

establishing in the Defaults Table 4-3types of 4-5

SSamples

CCID definition data set 8-15REXX procedure C-5

Securityabout 1-22native 1-22record data block 9-7SMF 9-1

Selection List panel 3-5Sequence processing 3-46Sequential data set 8-14Set

package data 1-15Setting up

inventory structure 1-7IP addresses C-7

Signin Action 1-19Site Information panel

display 3-7fields 3-8—3-15

Site-defined Symbolics 6-24SMF

about 9-1Action Records 9-3header block 9-5security records 9-2

SMF interfaceTYPE=ENVRNMNT parameters 6-10TYPE=MAIN parameters 6-9

Software life cycle 1-3Source

management 1-20output libraries 1-17

Specifying an Add Action for elements 8-6


Stagecomponent 1-6ID 4-3Information panel 3-16

Stamps, audit 1-21Stand-alone routes 4-5Storage 3-42Structure CA Endevor inventory

about 1-6classifying elements 1-13querying 1-14setting up 1-7

Structure, CA Endevor inventoryusing 1-7

Subsystemduplicate element names 5-2element registration 5-2

Subsystemscloning definitions 3-26defining 1-11definition of 1-6Definition panel 3-30Request panel 3-29

Suggested naming standards 3-42Symbolics 3-44System

cloning definitions 3-26converging within a route 4-7defining 1-10, 3-18definition of 1-6duplicate element names 5-2element registration 5-2identifying 3-5requiring CCIDs for 8-3tuning 15-14

System Definition 5-2, 5-3, 5-5, 5-6SYS/SBS Reg. Sev

System Definition panelcloning 3-27fields 3-20—3-25using 3-19

System Management FacilitiesSee SMF interface

System Request panel 3-18

TTable Defaults 1-2, 4-3Text editor 8-14Transfer Action

CCIDs updates 8-8

Transfer Action (continued)function 1-19with history 8-9without history 8-8

Tuningprocessors 15-13system 15-14

Typeadjust definitions A-4cloning definitions 3-26Data Set Request panel 3-50Data Sets panel 3-51defining 1-12, 3-32definition of 1-7Definition panel 3-34, A-4naming conventions 3-42Processing Sequence panel 3-47Request panel 3-32routes 4-5Sequence Request panel 3-46updating data set definitions 3-50

Type Processing SequenceType sequence 6-27TYPE=END macroTYPE=ENVRNMNT macro

See SMF interfaceTYPE=MAIN macro

See SMF interface

UUnloading elements A-3Update Action

CCIDs 8-6function 1-19

UpdatingAdd Action CCIDs 8-5CCIDs with Update Action 8-6Delete Action CCIDs 8-9Generate Action CCIDs 8-7Move Action CCIDs 8-8Restore Action CCIDs 8-10Retrieve Action CCIDs 8-7Transfer Action CCIDs 8-8

Userexit program C-4Options Menu 11-2, 11-4

Usingdefinition data set 8-14inventory structure 1-7panels 3-2

Index X-7

Using (continued)panels to define a map 4-3Point in Time Recovery 15-9Subsystem Definition panel 3-30System Definition panel 3-19Type

Data Set Request panel 3-50Definition panel 3-34Request panel 3-33Sequence Request panel 3-46

UtilitiesBC1JRELD A-4BC1JVALD A-5BC1PNCPY 15-8CONWRITE 15-2, 15-13Reload A-4Validate A-5

VValidate utility A-5Validating CCIDs 8-12VSAM

file processing 15-9LOG attribute 15-11record level sharing (RLS) 15-11

WWITH HISTORY A-7Working with elements 1-18


ca endevor change mangaer

Documents