Allfusion® Endevor® Change Manager: Administrator Guide R7

AllFusion Endevor
Change Manager
Administrator Guide
r7
F00164-1E
This documentation and related computer software program (hereinafter referred to as the
Documentation) is for the end user's informational purposes only and is subject to change or
withdrawal by Computer Associates International, Inc. (CA) at any time.
This documentation may not be copied, transferred, reproduced, disclosed or duplicated, in whole or
in part, without the prior written consent of CA. This documentation is proprietary information of CA
and protected by the copyright laws of the United States and international treaties.
Notwithstanding the foregoing, licensed users may print a reasonable number of copies of this
documentation for their own internal use, provided that all CA copyright notices and legends are
affixed to each reproduced copy. Only authorized employees, consultants, or agents of the user who
are bound by the confidentiality provisions of the license for the software are permitted to have access
to such copies.
This right to print copies is limited to the period during which the license for the product remains in
full force and effect. Should the license terminate for any reason, it shall be the user's responsibility to
return to CA the reproduced copies or to certify to CA that same have been destroyed.
To the extent permitted by applicable law, CA provides this documentation as is without warranty
of any kind, including without limitation, any implied warranties of merchantability, fitness for a
particular purpose or noninfringement. In no event will CA be liable to the end user or any third
party for any loss or damage, direct or indirect, from the use of this documentation, including without
limitation, lost profits, business interruption, goodwill, or lost data, even if CA is expressly advised of
such loss or damage.
The use of any product referenced in this documentation and this documentation is governed by the
end user's applicable license agreement.
The manufacturer of this documentation is Computer Associates International, Inc.
Provided with Restricted Rights as set forth in 48 C.F.R. Section 12.212, 48 C.F.R. Sections
52.227-19(c)(1) and (2) or DFARS Section 252.227-7013(c)(1)(ii) or applicable successor provisions.
First Edition, February 2005

2005 Computer Associates International, Inc. (CA)
All rights reserved.
All trademarks, trade names, service marks, and logos referenced herein belong to their respective
companies.
Contents
Chapter 1. Overview . . . . . . . . . . . . . . . . . . . .
1.1 The Defaults Table . . . . . . . . . . . . . . . . . . .
1.2 The Software Life Cycle . . . . . . . . . . . . . . . .
1.2.1 Basic Operations
. . . . . . . . . . . . . . . . .
1.3 Endevor Logical Structure . . . . . . . . . . . . . .
. . . . . . . . .
1.3.1 Using the Inventory Structure
1.3.2 Setting Up Endevor . . . . . . . . . . . . . . . .
1.3.2.1 Step 1: Determine Life Cycle Stages . . .
1.3.2.2 Step 2: Decide Stages for Endevor Control
1.3.2.3 Step 3: Define Environments . . . . . . . .
1.3.2.4 Step 4: Define Systems . . . . . . . . . . .
1.3.2.5 Step 5: Define Subsystems . . . . . . . . .
. . . . . . . . . . . .
1.3.2.6 Step 6: Define Types
1.3.3 Classifying Elements . . . . . . . . . . . . . . .
1.3.3.1 Querying the Endevor Structure . . . . .
1.4 Endevor Libraries
. . . . . . . . . . . . . . . . . . .
1.4.1 Library List . . . . . . . . . . . . . . . . . . . . .
1.5 Working with Elements . . . . . . . . . . . . . . . .
1.5.1 Endevor Actions . . . . . . . . . . . . . . . . . .
1.5.2 Actions by Job Function . . . . . . . . . . . . .
1.5.3 Reporting . . . . . . . . . . . . . . . . . . . . . .
1.5.4 Source and Output Management . . . . . . . .
1.5.5 Creating Executable Forms of Elements . . . .
1.5.6 Audit Stamps . . . . . . . . . . . . . . . . . . .
1.5.7 Packages . . . . . . . . . . . . . . . . . . . . . .
1.6 Security
. . . . . . . . . . . . . . . . . . . . . . . . .
1.6.1 Two Options . . . . . . . . . . . . . . . . . . . .
1.6.2 Endevor and Data Set Security . . . . . . . . .
1.7 Other Capabilities . . . . . . . . . . . . . . . . . . .
1.8 Name Masking . . . . . . . . . . . . . . . . . . . . .
1.8.1 Usage . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
Chapter 2. A Conceptual View of Endevor . . . . . . . . . . .

2.1 Inventory Management . . . . . . . . . . . . . . . . . . . . .
2.1.1 Automated Inventory Manager . . . . . . . . . . . . . .
2.1.1.1 Logical Structure . . . . . . . . . . . . . . . . . . . .
2.1.1.2 Physical Structure . . . . . . . . . . . . . . . . . . .
2.1.1.3 Interfaces to AllFusion CA-Panvalet and AllFusion
CA-Librarian . . . . . . . . . . . . . . . . . . . . . . . . . .
1-1
1-2
1-3
1-3
1-6
1-7
1-7
1-8
1-8
1-8
1-10
1-11
1-12
1-13
1-14
1-15
1-15
1-18
1-18
1-19
1-20
1-20
1-20
1-21
1-21
1-22
1-22
1-22
1-23
1-24
1-24
. . . . . . .
2-1
2-2
2-2
2-2
2-4
. . . . . . .
2-5
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Contents iii
2.2 Change Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

2.2.1 Automated Change Control . . . . . . . . . . . . . . . . . . . . . . . 2-6
2.2.1.1 Identifying and Tracking Changes . . . . . . . . . . . . . . . . 2-6
2.2.1.2 AllFusion Endevor Change Manager Interface for IBM's Tivoli
Information Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
2.2.1.3 Automating Processes . . . . . . . . . . . . . . . . . . . . . . . . 2-7
2.2.1.4 Establishing Source-to-Executable Synchronization . . . . . . 2-9
2.2.1.5 Audit Management . . . . . . . . . . . . . . . . . . . . . . . . 2-11
2.2.2 Endevor Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
2.2.3 Endevor's Software Control Language (SCL) . . . . . . . . . . . . 2-12
2.2.3.1 SCL Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
2.3 Configuration Management
. . . . . . . . . . . . . . . . . . . . . . . . 2-14
2.3.1 AllFusion Endevor Change Manager Automated Configuration
Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
2.3.1.1 Defining Software Configurations
. . . . . . . . . . . . . . . 2-14
2.3.1.2 Using Software Configurations . . . . . . . . . . . . . . . . . 2-17
2.4 Component Validation
. . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
2.5 Release Management
2.5.1 Automated Release Management
. . . . . . . . . . . . . . . . . . 2-20
2.5.1.1 Change Administration . . . . . . . . . . . . . . . . . . . . . . 2-20
2.5.1.2 How It Works . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21
2.5.1.3 Managing Production Turnover . . . . . . . . . . . . . . . . . 2-22
2.5.1.4 Managing Software Releases . . . . . . . . . . . . . . . . . . . 2-22
2.5.1.5 Release to Release Comparison . . . . . . . . . . . . . . . . . 2-24
2.6 Supporting Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25
2.6.1 AllFusion Endevor Change Manager Parallel Development
Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25
2.6.1.1 Managing Parallel Development Activities . . . . . . . . . . 2-25
. . . . . . . . . . . . . . . . . . . 2-26
2.6.1.2 Managing Vendor Updates
2.6.1.3 Basic PDM Operation . . . . . . . . . . . . . . . . . . . . . . . 2-26
2.6.2 Software Security Management . . . . . . . . . . . . . . . . . . . . 2-27
2.6.2.1 Native Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27
2.6.2.2 AllFusion Endevor Change Manager Interface for External
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28
2.6.3 Software Information Management . . . . . . . . . . . . . . . . . 2-28
2.6.3.1 Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
2.6.3.2 Reports
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
2.6.4 Endevor Benefit Summary . . . . . . . . . . . . . . . . . . . . . . . 2-30
Chapter 3. Defining Inventory Structures
3.1 Basic Panel Flow . . . . . . . . . . . . .
3.1.1 Introduction . . . . . . . . . . . . .
3.1.2 The Environment Options Menu .
3.1.3 Request and Selection Panels . . .
3.2 Displaying Site Information
. . . . . .
3.2.1 Site Information Panel . . . . . . .
3.2.2 Site Information Panel Fields . . .
3.2.2.1 Customer Name Field . . . . .
3.2.2.2 Function Controls Fields . . .
3.2.2.3 Options Fields . . . . . . . . .
3.2.2.4 Package Processing Fields . .
iv Administrator Guide
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
3-1
3-2
3-2
3-4
3-5
3-7
3-7
3-8
3-8
3-8
3-12
3-13
3.2.2.5 Control Data Set Names Fields . . . . . . . . .

3.2.2.6 Endevor Parmlib Information . . . . . . . . . .
3.2.2.7 CA-7 Data Set Name Fields . . . . . . . . . . .
3.3 Displaying Stage Information
. . . . . . . . . . . . . . .
3.3.1 Stage Information Panel . . . . . . . . . . . . . . . .
3.3.2 Stage Information Panel Fields . . . . . . . . . . . .
3.4 Defining Systems . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 System Request Panel . . . . . . . . . . . . . . . . .
3.4.2 Procedure: New System . . . . . . . . . . . . . . . .
3.4.3 System Definition Panel . . . . . . . . . . . . . . . .
3.4.4 Using the System Definition Panel . . . . . . . . . .
3.4.5 System Definition Panel Fields . . . . . . . . . . . .
3.4.5.1 Identification Fields . . . . . . . . . . . . . . . .
3.4.5.2 General Options Fields . . . . . . . . . . . . . .
3.4.5.3 Element Registration Options: . . . . . . . . . .
3.4.5.4 Signin/Signout Options Fields
. . . . . . . . .
3.4.5.5 Last System Backup Fields . . . . . . . . . . . .
3.4.5.6 Processor Translation Output Libraries Fields
3.5 Cloning System, Subsystem, and Type Definitions . . .
3.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.2 Procedure: Cloning a New System . . . . . . . . . .
3.5.3 System Definition Panel for Cloning . . . . . . . . .
3.5.4 System Definition Panel Fields . . . . . . . . . . . .
3.5.4.1 To Information . . . . . . . . . . . . . . . . . . .
3.5.4.2 From Information . . . . . . . . . . . . . . . . .
3.5.4.3 General Options . . . . . . . . . . . . . . . . . .
3.6 Defining Subsystems . . . . . . . . . . . . . . . . . . . . .
3.6.1 Subsystem Request Panel . . . . . . . . . . . . . . .
3.6.2 Procedure: Subsystems . . . . . . . . . . . . . . . . .
3.6.3 Subsystem Definition Panel . . . . . . . . . . . . . .
3.6.4 Using the Subsystem Definition Panel
. . . . . . .
3.6.5 Subsystem Definition Panel Fields . . . . . . . . . .
3.7 Defining Types . . . . . . . . . . . . . . . . . . . . . . . .
3.7.1 Type Request Panel . . . . . . . . . . . . . . . . . . .
3.7.2 Procedure: Types . . . . . . . . . . . . . . . . . . . .
3.7.3 Type Definition Panel . . . . . . . . . . . . . . . . .
3.7.4 Using the Type Definition Panel . . . . . . . . . . .
3.7.5 Type Definition Panel Fields . . . . . . . . . . . . .
3.7.5.1 Identification Fields . . . . . . . . . . . . . . . .
3.7.5.2 Element Options . . . . . . . . . . . . . . . . . .
3.7.5.3 Component List Options . . . . . . . . . . . . .
3.7.5.4 Libraries . . . . . . . . . . . . . . . . . . . . . . .
3.7.6 Type Naming Conventions . . . . . . . . . . . . . .
3.7.7 Suggested Naming Standards . . . . . . . . . . . . .
3.7.8 Element Storage Formats
. . . . . . . . . . . . . . .
3.7.8.1 Reverse Delta Considerations . . . . . . . . . .
3.7.8.2 Forward Delta Considerations . . . . . . . . . .
3.7.8.3 Full-Image Delta Considerations . . . . . . . .
3.7.9 Using Symbolics to Define Base and Delta Libraries
3.8 Defining the Type Processing Sequence . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . .
. . . . . . . .
3-14
3-15
3-15
3-16
3-16
3-16
3-18
3-18
3-18
3-19
3-19
3-20
3-20
3-21
3-21
3-23
3-24
3-24
3-25
3-25
3-25
3-26
3-26
3-26
3-27
3-27
3-28
3-28
3-28
3-29
3-29
3-29
3-31
3-31
3-32
3-33
3-33
3-34
3-34
3-35
3-40
3-40
3-41
3-41
3-42
3-42
3-43
3-43
3-43
3-45
Contents v
3.8.1 Type Sequence Request Panel . . . . . . . .

3.8.2 Procedure: Type Processing Sequence . . .
3.8.3 Type Processing Sequence Panel . . . . . .
3.8.3.1 Type Processing Sequence Panel Fields
. . . . . .
3.9 Updating Type Data Set Definitions
3.9.1 Type Data Set Request Panel . . . . . . . .
3.9.2 Procedure: Type Data Set Definitions . . .
3.9.3 Type Data Set Panel . . . . . . . . . . . . .
3.9.3.1 Type Data Set Panel Fields . . . . . . .
3.10 Displaying Environment Information . . . . .
3.10.1 Environment Information Panel . . . . . .
3.10.1.1 Environment Information Panel Fields
Chapter 4. Mapping . . . . . . . . . . . . . . . . .
4.1.1 Defining a Map . . . . . . . . . . . . . . .
4.1.2 Establishing Routes in the Defaults Table
4.1.3 Mapping Inventory Classifications . . . .
4.2 Design Strategies and Guidelines . . . . . . .
4.2.1 Routes . . . . . . . . . . . . . . . . . . . . .
4.2.2 Stand-alone Routes . . . . . . . . . . . . .
4.2.3 Converging Routes . . . . . . . . . . . . .
4.2.4 Converging Systems within a Route . . .
4.2.5 Implementation Checklist . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
Chapter 5. Element Registration

. . . . . . . . . . . . . . . . . . . . . . .
5.1 Overview
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Controlling Duplicate Element Names at the System and Subsystem
Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Controlling Duplicate Element Names at the Processor Group Level
5.3.1 Defining the Output Type . . . . . . . . . . . . . . . . . . . . . . .
Chapter 6. Optional Features
. . . . . . . . . . . . . . . . . .
6.1 Endevor Optional Feature Table ENCOPTBL . . . . . . .
6.1.1 Optional Feature Table Source . . . . . . . . . . . . .
6.2 The Features Discussed in This Chapter . . . . . . . . . .
6.3 The Features Not Discussed in this Chapter . . . . . . . .
6.4 The CCID Definition Data Set . . . . . . . . . . . . . . . .
6.4.1 Install the CCID Definition Data Set . . . . . . . . . .
6.4.2 Step 1: Allocate the Data Set . . . . . . . . . . . . . .
6.4.3 Step 2: Initialize the Data Set . . . . . . . . . . . . . .
6.4.4 Step 3: Add the Data Set Name to the Defaults Table
6.5 The SMF Interface . . . . . . . . . . . . . . . . . . . . . . .
6.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.2 Set the SMF Parameters in the Defaults Table . . . .
6.5.3 TYPE=MAIN Parameters . . . . . . . . . . . . . . . .
6.5.4 TYPE=ENVRNMNT Parameters . . . . . . . . . . . .
6.6 The Endevor AllFusion CA-Panvalet Interface . . . . . .
6.6.1 Link-Edit the Access Module . . . . . . . . . . . . . .
6.6.2 Step 1: Edit BC1JPAN . . . . . . . . . . . . . . . . . .
6.6.3 Step 2: Run BC1JPAN . . . . . . . . . . . . . . . . . .
vi Administrator Guide
3-45
3-45
3-46
3-47
3-49
3-49
3-49
3-50
3-50
3-52
3-52
3-52
. . . . . . . . . . . . .
. . . . . . . . . . . . .
.
.
.
.
.
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
4-1
4-2
4-2
4-3
4-4
4-4
4-4
4-5
4-6
4-7
5-1
5-2
5-3
5-5
5-7
6-1
6-2
6-2
6-21
6-23
6-24
6-24
6-24
6-24
6-25
6-26
6-26
6-26
6-26
6-27
6-28
6-28
6-29
6-29
6.6.4 Step 3: Set the AllFusion CA-Panvalet Parameters in the

Defaults Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.7 The ++CONTROL Password Interface . . . . . . . . . . . . . . . . . .
6.7.1 Install the ++CONTROL Password Interface . . . . . . . . . . . .
6.7.2 Step 1: Edit BC1JCNTL . . . . . . . . . . . . . . . . . . . . . . . . .
6.7.3 Step 2: Run BC1JCNTL . . . . . . . . . . . . . . . . . . . . . . . . .
6.8 The Endevor AllFusion CA-Librarian Interface . . . . . . . . . . . . .
6.8.1 External and Internal Libraries . . . . . . . . . . . . . . . . . . . .
6.8.2 Set the AllFusion CA-Librarian Parameters in the Defaults Table
6.8.3 Should You Customize for AllFusion CA-Librarian? . . . . . . .
6.8.4 Considerations When Customizing . . . . . . . . . . . . . . . . .
6.8.5 Customize Your Site for the AllFusion CA-Librarian . . . . . . .
6.8.6 Step 1: Define Sequence Number Columns . . . . . . . . . . . . .
6.8.7 Edit the BC1JLIBR JCL . . . . . . . . . . . . . . . . . . . . . . . . .
6.8.8 Step 2: Define Endevor Types
. . . . . . . . . . . . . . . . . . . .
6.8.9 Points to Remember . . . . . . . . . . . . . . . . . . . . . . . . . .
6.9 Alternate ID Support
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.9.1 Implement Alternate ID Support . . . . . . . . . . . . . . . . . . .
.
6.9.2 Step 1: Set the Alternate ID Parameters in the Defaults Table
6.9.3 Step 2: Build a Security Profile for Endevor Libraries . . . . . .
6.10 Site-Defined Symbolics . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.10.1 Defining Site Symbolics . . . . . . . . . . . . . . . . . . . . . . . .
6.10.2 Updating C1DEFLTS . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.11 Parmlib Data Set
6.11.1 Defining the Parmlib in the C1DEFLTS . . . . . . . . . . . . . .
6.12 Type Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.12.1 Implementing Global Type Sequencing . . . . . . . . . . . . . .
6.12.2 Defining the Type Sequence Member in the C1DEFLTS . . . .
Chapter 7. Site Symbolics . .
7.1 Site-Defined Symbolics . .
7.2 Site Symbolics Overview .
7.2.1 Defining Site Symbolics
7.2.2 Updating C1DEFLTS .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 8. Using CCIDs . . . . . . . . . . . . . . . . . . . . . .

8.1 Overview
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 What CCIDs and/or Comments Indicate
. . . . . . . . . .
8.2.1 Six Fields . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3 Requiring CCIDs . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.1 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.2 Action Prompt Panel . . . . . . . . . . . . . . . . . . . .
8.4 When Endevor Updates CCID Fields . . . . . . . . . . . . .
8.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.2 Add Action CCID Updates . . . . . . . . . . . . . . . .
8.4.2.1 Specifying an Add Action for a New Element . .
8.4.2.2 Specifying an Add Action for an Existing Element
8.4.3 Update Action CCID Updates . . . . . . . . . . . . . .
8.4.4 Retrieve Action CCID Updates . . . . . . . . . . . . . .
. . . . . . . . . . . . .
8.4.5 Generate Action CCID Updates
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
6-29
6-30
6-30
6-30
6-32
6-33
6-33
6-33
6-34
6-34
6-35
6-35
6-36
6-37
6-38
6-39
6-39
6-39
6-40
6-41
6-41
6-42
6-43
6-43
6-44
6-44
6-44
7-1
7-2
7-3
7-3
7-4
8-1
8-2
8-3
8-3
8-4
8-4
8-5
8-6
8-6
8-6
8-7
8-7
8-8
8-8
8-8
Contents vii
8.4.5.1 Specifying a Generate Action without Copyback

.
8.4.5.2 Specifying a Generate Action with Copyback
8.4.6 Move Action CCID Updates
. . . . . . . . . . . . . .
8.4.6.1 Specifying a Move Action without History . . .
8.4.6.2 Specifying a Move Action with History . . . . .
8.4.7 Transfer Action CCID Updates . . . . . . . . . . . . .
8.4.7.1 Specifying a Transfer Action without History .
8.4.7.2 Specifying a Transfer Action with History . . .
8.4.8 Delete Action CCID Updates . . . . . . . . . . . . . .
8.4.9 Restore Action CCID Updates . . . . . . . . . . . . .
8.4.10 Summary CCID Impact Chart . . . . . . . . . . . . .
8.5 Predefining CCIDs . . . . . . . . . . . . . . . . . . . . . . .
8.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.2 CCID Validation . . . . . . . . . . . . . . . . . . . . . .
8.5.3 Endevor CCID Definition Data Set . . . . . . . . . . .
8.5.3.1 Creating a CCID Definition Data Set . . . . . . .
8.5.3.2 The Purpose of a Sequential Data Set . . . . . .
8.5.3.3 Editing the File Using the ISPF Text Editor . . .
8.5.4 Using the CCID Definition Data Set . . . . . . . . . .
8.5.4.1 Sample CCID Definition Data Set . . . . . . . . .
viii Administrator Guide
. . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
8-9
8-9
8-9
8-9
8-10
8-10
8-10
8-11
8-11
8-12
8-12
8-14
8-14
8-14
8-15
8-15
8-16
8-16
8-16
8-17
Chapter 9. SMF Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.1 Record Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.2 SMF Security Records . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.3 SMF Action Records . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 DSECT Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.2 $SMFHDDS DSECT: SMF Header Block . . . . . . . . . . . . . . .
9.2.2.1 SMF Header Block Field Descriptions . . . . . . . . . . . . . .
9.2.3 $SMFREC1 DSECT: Security Record Data Block
. . . . . . . . . .
9.2.3.1 Security Record Data Block Field Descriptions . . . . . . . . .
9.2.4 $SMFREC2 DSECT: Action Record Data Block
. . . . . . . . . .
9.2.4.1 Action Record Data Block Field Descriptions . . . . . . . . .
9.2.5 $SMFBKDS DSECT: Action-Specific Blocks . . . . . . . . . . . . .
9.2.5.1 Action-Block Header Field Descriptions (SM2BHDDS) . . .
9.2.5.2 Environment Action-Block Detail Field Descriptions
(SM2ENVDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.5.3 Last Change Action-Block Detail Field Descriptions
(SM2LCGDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.5.4 Processor Information Action-Block Detail Field Descriptions
(SM2LPRDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.5.5 Request Parameter Info Action-Block Detail Field
Descriptions (SM2REQDS) . . . . . . . . . . . . . . . . . . . . . . . .
9.2.6 $SMFREC4 DSECT: Environment Record Data Blocks . . . . . .
9-1
9-2
9-2
9-2
9-3
9-5
9-5
9-5
9-6
9-7
9-8
9-11
9-12
9-13
9-16
Chapter 10. Global Type Sequencing . . . . .

10.1 Allocate the Parmlib Data Set . . . . . . . .
10.2 Create Your Site's Type Sequence Member
10.2.1 Syntax Rules for Type Records . . . .
10.2.2 Sample Type Sequence File . . . . . .
10-1
10-3
10-4
10-5
10-6
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
9-17
9-19
9-19
9-19
9-20
10.2.3 Build Utility for the Type Sequence Member

10.3 Define the Type Processing Member
. . . . . .
Chapter 11. The User Options Menu Facility
11.1 Overview . . . . . . . . . . . . . . . . . . .
11.1.1 Menu Functions . . . . . . . . . . . .
11.2 User Option Menu Panel Overview . . .
11.2.1 Source . . . . . . . . . . . . . . . . . .
11.2.2 Modifying the User Options Menu .
. . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
Chapter 12. The ISPF Dialog Options Configuration Table

12.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.1.1 What Is This Feature? . . . . . . . . . . . . . . . . . .
12.1.2 What You Can Change . . . . . . . . . . . . . . . . .
12.1.3 What You Cannot Change . . . . . . . . . . . . . . .
12.2 The Default Configuration Table . . . . . . . . . . . . . .
12.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . .
12.3 Dialog Options Fields . . . . . . . . . . . . . . . . . . . .
12.3.1 JCL (BC1JCNFG) . . . . . . . . . . . . . . . . . . . . .
Chapter 13. The Defaults Table . . . .
13.1 Overview . . . . . . . . . . . . . . .
13.1.1 About the Defaults Table . . .
13.1.2 The C1DEFLTS Macro . . . .
13.1.3 Editing the Defaults Table . .
13.1.4 Warning . . . . . . . . . . . . .
13.1.5 Assembling the Defaults Table
13.2 The TYPE=MAIN Macro . . . . . .
13.2.1 Example . . . . . . . . . . . . .
13.3 The TYPE=ENVRNMNT Macro .
13.3.1 Example . . . . . . . . . . . . .
13.3.2 Selecting a BATCHID Option
. . . . . .
13.4 The TYPE=END Macro
13.4.1 Example . . . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
Chapter 14. The Alternate Defaults Table

. . . . . . .
14.1 About ENUXSITE . . . . . . . . . . . . . . . . . . . .
14.1.1 What Is the ENUXSITE Program?
. . . . . . .
14.1.2 Parameters Passed to the ENUXSITE Program
14.1.3 How to Use the ENUXSITE Program . . . . .
14.1.4 How to Create an Alternate Defaults Table . .
14.1.5 Example . . . . . . . . . . . . . . . . . . . . . . .
Chapter 15. Performance and Tuning . . . . . . . .
15.1 Overview . . . . . . . . . . . . . . . . . . . . . . .
15.2 Choosing Between Delta Formats . . . . . . . .
15.2.1 Overview . . . . . . . . . . . . . . . . . . . .
15.2.2 Converting from Forward to Reverse Deltas
15.2.3 Full-Image Deltas . . . . . . . . . . . . . . .
15.3 Setting the Element Delta Consolidation Level
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
10-6
10-8
11-1
11-2
11-2
11-3
11-3
11-4
12-1
12-2
12-2
12-2
12-2
12-3
12-3
12-5
12-13
13-1
13-2
13-2
13-2
13-2
13-3
13-3
13-5
13-5
13-18
13-18
13-22
13-24
13-24
14-1
14-2
14-2
14-2
14-2
14-3
14-3
15-1
15-2
15-3
15-3
15-4
15-4
15-5
Contents ix
15.3.1 Two Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15.4 Mapping Multiple Environments . . . . . . . . . . . . . . . . . . . . .
15.4.1 Before Implementation . . . . . . . . . . . . . . . . . . . . . . . .
15.5 Selecting a Library Type for Base and Delta Members . . . . . . . .
15.5.1 Benefits of Library Types . . . . . . . . . . . . . . . . . . . . . . .
15.5.2 Converting from One Library Type to Another . . . . . . . . .
15.6 Using CA-L-Serv for Endevor's VSAM File Processing
. . . . . . .
15.6.1 Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.6.2 Setting the RECBUFFSIZE Parameter
. . . . . . . . . . . . . . .
15.6.3 Monitoring CA-L-Serv's Performance . . . . . . . . . . . . . . .
15.6.3.1 Evaluating Buffer Pool Usage . . . . . . . . . . . . . . . . .
15.6.3.2 Displaying Information about the Communications Server
15.7 Using z/OS SYSPLEX VSAM Record Level Sharing (RLS) Support
for MCFs and Package Data Set . . . . . . . . . . . . . . . . . . . . . . . .
15.7.1 Implementing RLS . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.8 Tuning Your Processors . . . . . . . . . . . . . . . . . . . . . . . . . .
15.8.1 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.9 Tuning Your System . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.9.1 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appendix A. Converting Delta Formats . . . . . . . . . . . . . . . . .
A.1 Steps for Converting Forward to Reverse Delta . . . . . . . . . .
A.1.1 Procedure Summary . . . . . . . . . . . . . . . . . . . . . . . .
A.1.2 Step 1: Analyzing Existing Types . . . . . . . . . . . . . . . .
A.1.3 Step 2: Resize and Allocate New Base Libraries . . . . . . .
A.1.4 Step 3: Resize the Delta Libraries . . . . . . . . . . . . . . . .
A.1.5 Step 4: Evaluate and Modify Processors . . . . . . . . . . . .
A.1.6 Step 5: Run a Full Unload of Each Environment . . . . . . .
A.1.7 Step 6: Adjust Type Definitions . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . .
A.1.8 Step 7: Reload Inventory by System
A.1.9 Step 8: Validate the Results . . . . . . . . . . . . . . . . . . . .
A.2 Additional Conversion Notes . . . . . . . . . . . . . . . . . . . . .
A.2.1 Reverse Delta Format . . . . . . . . . . . . . . . . . . . . . . .
A.3 Procedure for Converting Forward/Reverse Delta to Full-Image
Delta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appendix B. Catalog Utilities . . . . . . . . . . . . . . . . . . . . . .
B.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2 Building the Element Catalog . . . . . . . . . . . . . . . . . . . .
B.2.1 Step 1: Converting Your Existing MCF VSAM Data Sets .
B.2.2 Step 2: Converting Your Existing Package VSAM Data Sets
B.2.3 Step 3: Defining the MCF Catalog Data Set . . . . . . . . .
B.2.4 Step 4: Updating the C1DEFLTS Table . . . . . . . . . . . .
B.2.5 Step 5: Running the Catalog Build Utility . . . . . . . . . .
B.3 Endevor Considerations . . . . . . . . . . . . . . . . . . . . . . . .
B.4 Catalog Rename Utility . . . . . . . . . . . . . . . . . . . . . . . .
B.4.1 Catalog Rename Utility Sample Report . . . . . . . . . . . .
B.5 Catalog Synchronization Utility . . . . . . . . . . . . . . . . . . .
B.5.1 Catalog Synchronization Utility JCL . . . . . . . . . . . . . .
B.5.2 Catalog Synchronization Utility Syntax . . . . . . . . . . . .
B.5.3 Catalog Synchronization Utility Sample Report . . . . . . .
x Administrator Guide
15-5
15-6
15-6
15-7
15-7
15-9
15-10
15-10
15-10
15-10
15-11
15-11
15-12
15-13
15-14
15-14
15-15
15-15
. .
A-1
A-2
A-2
A-2
A-3
A-3
A-3
A-3
A-4
A-4
A-5
A-6
A-6
. .
A-7
. . . .
B-1
B-2
B-3
B-3
B-3
B-4
B-4
B-4
B-5
B-6
B-7
B-8
B-8
B-9
B-10
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. . . .
. . . .
. . . .
. . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . .
Appendix C. Interfacing Endevor with CA Common Services

C.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.2 Formatting Endevor Messages . . . . . . . . . . . . . . . . .
C.3 How the Interface Works . . . . . . . . . . . . . . . . . . . .
C.4 Calling the Interface From a User Exit . . . . . . . . . . . .
C.5 Calling the Interface From a Processor . . . . . . . . . . . .
C.5.1 Sample Endevor Processor Fragment . . . . . . . . . .
C.5.2 REXX Procedure Sample . . . . . . . . . . . . . . . . .
C.6 Setting Up the IP Addresses of Event Consoles . . . . . .
Appendix D. Long Name and HFS File Support . .
D.1 Long Name and HFS Support Overview . . . . .
D.1.1 HFS Path Name
. . . . . . . . . . . . . . . . .
D.1.2 HFS Files . . . . . . . . . . . . . . . . . . . . . .
D.1.3 Element Names . . . . . . . . . . . . . . . . . .
D.1.4 Long Name Support and Endevor Interfaces
D.2 Long Name Elements . . . . . . . . . . . . . . . . .
D.2.1 Adding and Retrieving Long Name Elements
D.2.2 Storing Long Name Elements . . . . . . . . .
D.2.3 Displaying Element Information . . . . . . . .
. . . . . . . . . . . . . .
D.3 HFS Files and Directories
D.3.1 HFS Directories and Endevor Libraries . . . .
D.3.2 Using Site Symbolics for Type Definitions . .
D.3.3 HFS Directories and Endevor Actions . . . .
D.3.4 HFS Files and Endevor Actions . . . . . . . .
D.4 HFS RECFM Field in Type Definition Panel . . .
D.4.1 Parameters . . . . . . . . . . . . . . . . . . . . .
Appendix E. Working with Binary Files
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
C-1
C-2
C-3
C-4
C-5
C-6
C-6
C-7
C-8
D-1
D-2
D-2
D-2
D-3
D-4
D-6
D-6
D-7
D-7
D-8
D-8
D-8
D-9
D-9
D-10
D-10
. . . . . . . . . . . . . . . . . . .
E-1
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
F-1
F-2
F-3
F-4
F-5
F-6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
X-1
Appendix F. Email Notification .

F.1 ESMTPTBL . . . . . . . . . . .
F.2 Email Notification Components
F.3 $ESMTP Macro . . . . . . . . .
F.4 Sample ESMTPTBL
. . . . . .
F.5 BC1JSMTP . . . . . . . . . . . .
Index
. . . . . .
. . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
Contents xi
xii Administrator Guide
Chapter 1. Overview
AllFusion Endevor Change Manager (Endevor) is an integrated set of
management tools that is used to automate, control, and monitor your
applications' development process. Using Endevor, you can:
Automatically compare and track your changes against production,
creating an online change history. This speeds up the debugging process
and 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 a
single 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, analyzing
impacts, and standards checking functions) to any component type,
dramatically simplifying the standardization process.
Put change packages and approvals online, eliminating change-related
paperwork.
View or retrieve prior levels of any element.
Report on element definition, content, and change history.
Enforce change control procedures.
Endevor is implemented and run under z/OS, within the TSO ISPF
environment, and in batch.
This manual explains the administrative aspects of Endevor. This rest of this
chapter introduces basic Endevor concepts.
Chapter 1. Overview 1-1
1.1 The Defaults Table
1.1 The Defaults Table

The Endevor Defaults Table contains your global system information, such as
Endevor options installed at your site, Endevor control data set names, and
settings available for Endevor features. Although all of these parameters are
set at system installation, you may need to change the Defaults Table if your
site purchases a new Endevor product, your library names change, or you
want to tailor the information entered by the system installer. The table
comprises a set of "C1DEFLTS" macros which, when assembled and
link-edited, are known collectively as the Defaults Table.
The Defaults Table should reside in an authorized data set.
See the chapter "The Defaults Table," for a sample of the C1DEFLTS table and
a detailed description of the parameters available within the table.
1-2 Administrator Guide
1.2 The Software Life Cycle

Endevor allows you to automate and control the movement of software
through your software life cycle.
Software life cycles are site-specific. A representative life cycle might consist
of 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. Endevor can be implemented to
adapt to any software life cycle requirements.
1.2.1 Basic Operations

Normal change procedures include:
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 life

cycle.
Emergency change procedures include:

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 software

life cycle.
1.3 Endevor Logical Structure

Endevor helps to manage the software life cycle by providing a consistent and
flexible logical structure for classifying software inventory. There are six
components to this inventory structure: environments, stages, systems,
subsystems, types, and elements. Environments, stages, systems, subsystems,
and types are set up by the Endevor administrator. Users act on elements.
These terms are defined below.
Term
Description
Environment
Functional areas within an organization. For example, there

might be separate development and production environments.
There is no limit to the number of environments that may be
defined.
Stage
The stages in the software life cycle. (See 1.2, The Software
Life Cycle on page 1-3 for an example.) Each environment
always has two stages. Each stage is assigned a unique name
and ID, representing their place life cycle. For example, TEST
and an ID of 1, or QA and an ID of 2. Stages are referred to
in this manual as Stage 1 (the first stage in an environment)
and Stage 2 (the second stage in an environment). Stages can
be linked together to establish unique promotion routes for
program inventory within and between environments. These
routes make up the map for a site.
System
The applications at a site. For example, there might be

financial and manufacturing applications. A system must be
defined to each environment in which it is used.
Subsystem
A specific application within a system. For example, there

might be purchase order and accounts payable applications
within the financial system. Keep in mind that:
There must be at least one subsystem per system. A
subsystem must be defined to each system in which it is
used. For example, to create subsystem PO within system
Finance in the environments TEST, QA, and PROD, you
must define subsystem PO in each environment.
A subsystem can have the same name as the system to
which you define it.
Term
Description
Type
Categories of source code. For example, you might create the

following types:
COBOL - for COBOL code
COPYBOOK - for copybooks
JCL - for JCL streams
You must define a type to each stage in which you want to
use it.
Element
Partitioned data set (PDS) members, AllFusion

CA-Panvalet, AllFusionCA-Librarian, or sequential data
sets that have been placed under control of Endevor. By
default, the element name is the member name. Each element
is classified by system, subsystem, and type. Its environment
and stage determine its location in the software life cycle.
1.3.1 Using the Inventory Structure

The Endevor inventory structure allows you to:
Work with program modules without having to know where they are
physically located, or how they are compiled.
List all the program components that make up an application, regardless of
type.
Determine the location(s) of an element simply by entering the element
name on a display screen.
Act on a cross section of your program inventory. For example, Endevor
allows you to list all COBOL code in your shop, or promote an entire new
release of the payroll application with a single command.
1.3.2 Setting Up Endevor

The Endevor administrator builds an inventory structure based on the stages
in your site's software life cycle. There are six steps in setting up an inventory
structure:
1. Determine the stages in the software life cycle.
2. Decide which stages should be put under the control of 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 processing
required 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 life
cycle:
DEV
UNITTEST
QA
EMER
PROD
1.3.2.2 Step 2: Decide Stages for Endevor Control

You can decide to put some or all of the stages in your life cycle under control
of Endevor. In this example, assume the last four stages of the life cycle are
under the control of Endevor:
UNITTEST
QA
EMER
PROD
This means that program development takes place outside of Endevor.

While this is a fairly typical life cycle, keep in mind that Endevor can be
adapted to any life cycle.
1.3.2.3 Step 3: Define Environments

Environment is the Endevor term for functional areas in your organization. In
this example, assume that the UNITTEST and QA stages in the life cycle are
part of the development function, and that production applications and their
maintenance are part of a function called production. The administrator
defines environment TEST to include Stages UNITTEST and QA, and a second
environment called PROD, that includes Stages EMER and PROD.
Development activities take place in a development library, outside of
Endevor.
The Environment Map The Endevor administrator might decide to establish

the following route for inventory at this site that promotes inventory from
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).
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 one
subsystem, MFG.
1.3.2.6 Step 6: Define Types

You must define types to each system/stage combination in which you plan to
use them. All subsystems defined to a system can use the types defined to
that system. You must define types at both stages in an environment. In this
example, system FINANCE has available the types COBOL (COBOL code), JCL
(JCL streams), and COPYBOOK (copybooks). System MFG has available the
types ASSEM (Assembler code), JCL, and MACRO (Macros).
1.3.3 Classifying Elements

Endevor classifies elements according to the inventory structure you set up.
Each element is described uniquely in terms of its:
Location in the software life cycle. This is determined by the environment
and stage where it resides.
Inventory classification. This is determined by the system, subsystem, and
type with which it is associated.
This is illustrated by the following diagram:
For example, in this diagram:

This module
Is located in
PROG01
Environment TEST
Stage UNITTEST
Is classified as
Type COBOL
Subsystem PO
System FINANCE
JCL22Q
Environment TEST
Stage QA
Type JCL
Subsystem MFG
System MFG
COPY33
Environment TEST
Stage QA
Type COPYBOOK
Subsystem AP
System FINANCE
1.3.3.1 Querying the Endevor Structure

The Endevor classification scheme allows users to produce lists of elements by
environment, stage, system, subsystem, type, or any combination of these
categories. For example, using the preceding example, you could query the
system for the following lists:
This query
Produces
Show me all the JCL in the shop
JCL56
JCL008
JCL22Q
Show me all the software currently in QA
PROGX
JCL008
COPY33
PGM00
JCL22Q
MAC02
Show me all the manufacturing software currently being

unit tested
PGMA1
PGMA2
MAC02

1.4.1 Library List
To implement an inventory structure, certain libraries must first be defined
and allocated. Brief descriptions of these libraries follow.
Library
Description
Master Control File

libraries
There is one Master Control File (MCF) for every stage. A Master Control
File stores system, subsystem, and type definitions, the names of the elements
currently 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 for
long or mixed-case element names.
When an element with a long or mixed-case name is added to Endevor, the
original name is maintained in the element catalog, and an
Endevor-generated short name (eight characters) is stored in the associated
master control file entry. An additional VSAM KSDS file, known as the
catalog Cross Reference file, is also maintained, so that actual element names
can be retrieved using the short element name that is stored in the MCF.
The element catalog contains one element catalog record for each
element-type occurrence and each element catalog record contains a data
segment 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:
1. The first 240 characters of the element name. The remaining 15
characters of the element name are actually stored in the base portion of
the record.
2. The element type name
The information supplied to Endevor determines whether the element catalog
or the MCF file is used during element searches. For example:
If the system and subsystem names are provided, but not the element
name the MCF is searched.
If an element name is specified the element catalog is searched;
regardless of the system and subsystem specifications.)
Library
Description
Package data set
There is one package data set per site. Endevor stores all packages built at
the site, and related information, in this data set.
You define the package data set for your site in the Defaults Table.
Base and delta

libraries
Endevor uses base and delta libraries to store source code. Base libraries
store source when it is first added to Endevor. Delta libraries store changes
made to the source. Generally, there is one set of base and delta libraries
associated with each type definition.
Base and delta libraries are defined during implementation on the type
definition panel.
ACM Root and XREF

Libraries
Endevor uses these libraries to store the name of each element and its related
components. This data set is required if your site uses the ACM Query
Facility. See the Automated Configuration Option Guide for more information.
The ACM library for your site is defined in the C1DEFLTS table.
Output libraries 1
Endevor uses output libraries to store executable forms of programs

produced by processors. Allocate these libraries by stage.
You allocate output libraries during Endevor implementation.
Source output
libraries
Endevor uses source output libraries to store copybooks, assembler macros,

or JCL procedures that are copied elsewhere and therefore have to be
available in full source form.
Note: Source output libraries are type-specific. You can define a source
output library for each type in a stage, or share one library across types.
Generally, source output libraries are not needed if you store elements in
reverse delta format.
You define the source output libraries on the type definition panel.
Processor load and

listing libraries 1
Endevor uses processor load libraries to store the executable form of Endevor
processors. Allocate one processor load library for both stages of your
production environment; point to these libraries from all other stages.
Processor listing libraries are optional. Endevor uses them to store listings
when processors are compiled.
Endevor listing
libraries 1
Used to store compiler listings produced by the CONLIST utility. A single

library can be shared across systems.
Listing libraries are optional if you do not use CONLIST in your processors.
You allocate listing libraries during Endevor implementation.
Include libraries
Endevor uses include libraries to store the full form of AllFusion

CA-Panvalet (++INCLUDE) and AllFusion CA-Librarian (-IN) include
statements.
You allocate include libraries on the type definition panel.
Library
Description
Processor output
libraries 1
These are libraries that you refer to in processors, to which processors write
their output. Processor output libraries can be source libraries, executable
libraries, or listing libraries.
Note: 1 Processors only

The following table summarizes where each of these libraries should be
allocated in a sample software life cycle:
Library Name
C1DEFLTS
DEV
TEST
DEV QA
PROD
EMERG
PROD
PROD
Master control files
Element Catalog
ACM Root library
ACM XREF library
Package data set
Base and delta libraries, by

type
Output libraries, by type
Source output libraries, by

type
Processor load libraries
Processor output libraries

(source, executable, list)
Include libraries, by type
1.5 Working with Elements

1.5.1 Endevor Actions
You manipulate Endevor inventory by executing ENDEVOR commands called
actions. Some actions are available in both foreground and in batch, while
others are available only in batch. Batch actions are also available when you
build packages.
The User Guide explains how to execute actions in foreground and submit
batch action requests.
The SCL Reference Guide contains the syntax for Endevor's Software Control
Language (SCL). SCL allows you to code Endevor batch action requests.
The following table summarizes Endevor actions and their availability:
Action
Available in
Foreground
Available
in Batch
Function
Add
Puts a member under

Endevor control from an
external data set.
Archive
Writes the current version of

an element to a sequential
data set.
Copy
Copies an element from an

archive data set to a data set
external to Endevor.
Erases base and delta forms

of an element and removes
related information from a
Master Control File.
Delete
Display
Generate
List
Displays information about

an element.
x
Creates an executable form

of an element.
Creates a list of elements

that meet specific selection
criteria. One effective use of
this function is to perform
impact analysis.
Action
Available in
Foreground
Available
in Batch
Function
Move
Moves elements between

stages, within or across
environments.
Print
Prints element or member

information.
Restores elements to Endevor

from an archive data set.
Restore
Retrieve
Copies elements from

Endevor to an external data
set.
Signin
Removes the user signout

associated with an element.
Moves elements between

locations that are not on the
same map route.
Updates an element from an

external data set.
Transfer
Update
1.5.2 Actions by Job Function

A typical site might include the following job functions:
Development
QA/Test
Turnover
Audit
Management
Endevor administration
The following table summarizes, for each job function, the actions that
someone might perform:
Action
Dev
QA/Test
Add/Update
Turnover
Audit
Mgmnt Admin
x
Archive
Copy
Delete
Action
Dev
QA/Test
Turnover
Audit
Mgmnt Admin
Display
Generate
List
Move
Print
x
x
x
Restore
x
x
Retrieve
Signin
Transfer
x
x
x
1.5.3 Reporting
Endevor provides a full set of standard reports. For more information, see the
Reports Guide
1.5.4 Source and Output Management

As it executes each action request, Endevor categorizes the processing as
source management or output management.
Source management deals with that aspect of processing that maintains the
element source and MCF definitions; that is, updates to the Master
Control File and to the base and delta libraries.
Output management relates to any processing that creates or maintains
data sets related to the element being processed. These data sets include
the source output libraries, processor listing and load libraries (applicable
for element type PROCESS only), user-defined libraries, and INCLUDE
libraries.
Note: Output management is only available if you have the Endevor
processor component.
1.5.5 Creating Executable Forms of Elements

Endevor uses OS JCL streams called processors to create executable forms of
source code, including source modules, object modules, load modules, and
listings.
There are three kinds of processors:

Generate processors execute automatically when an element is added or
updated in the entry stage, or generated in either stage. Optionally,
generate processors execute when an element is restored or transferred to
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 the
element, 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 for
transfer, move and archive requests.) Generally, the delete processor
deletes any output that was created by the corresponding generate
processor.
Processors are combined into processor groups. A processor group consists of
one generate, one move, and one delete processor, as well as the symbolic
overrides for the processors' JCL. For more information, see the Extended
Processors Guide.
1.5.6 Audit Stamps

Endevor can place an encrypted audit stamp, called a footprint, in the output
source, object, or load modules that are created by processors. The footprint
provides an integrity check between the source form of an element and its
executable form.
1.5.7 Packages
Endevor packages allow you to formalize your use of actions by:
Creating sets of actions that can be tracked, maintained, and reused as a
unit.
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
1.6.1 Two Options
Endevor provides two functional security options:
A native security facility
The Endevor External Security Interface (Endevor ESI)
A native security facility comes with Endevor. It enables you to secure
Endevor functions (access and actions) by using security tables. For more
information, see the Security Guide.
The External Security Interface is an optional feature that enables you to secure
Endevor functions (access and actions) through the z/OS Security Access
Facility (SAF) and in conjunction with the installation security package on your
system. It does this by allowing you to define the rules for function security in
your installation security package (RACF, eTrust CA-ACF2 Security,
eTrust CA-Top Secret Security) rather than in the native tables supplied
with Endevor. For more information on enabling and using Endevor ESI, see
the Security Guide.
1.6.2 Endevor and Data Set Security

Endevor does not provide data set security. Data set security is performed by
an installation security package, such as:
RACF
eTrust CA-ACF2 Security
eTrust CA-Top Secret Security
Computer Associates recommends that you implement data set security to
prevent unauthorized access to the data sets controlled by Endevor. For
information on how to accomplish this using your installation security
package, see the Security Guide.
1.7 Other Capabilities
1.7 Other Capabilities

In conjunction with other Computer Associates products, Endevor can provide:
Configuration management, using the Endevor Automated Configuration
Manager (ACM). For more information, see the Automated Configuration
Option Guide.
Parallel development controls using the Endevor Parallel Development
Manager (PDM). For more information, see the Parallel Development Option
Guide.
Automated coordination of all DB2 processes, using the Endevor for DB2
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 a
particular 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
1.8.1 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 two ways to specify external file names:
When coded as the only character of a search string, Endevor returns all
members of the search field. For example, if you coded the statement
ADD ELEMENT *, all elements would be added.
When coded as the last character of a search string, Endevor returns all
members of the search field beginning with the characters in the search
string preceding the wildcard. For example:
The statement ADD ELEMENT UPD* would add all elements
beginning 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 statement
ADD ELEMENT U*PD* would result in an error.
1.8 Name Masking
The placeholder (%), which represents any one character in a string, can also
be used in one of two ways:
When coded as the last character in a string, Endevor returns all members
of the search field, beginning with the characters in the search string
preceding the placeholder, but which have no more characters than were
coded in the search string.
If you coded the statement ADD ELEMENT UPD%, only those
elements with four-character-long names beginning with "UPD" (UPD1
or 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 search
string. The statement ADD ELEMENT U%PD% would return all elements
with five-character-long names that have U as the first character, and PD
third and fourth.
The wildcard and the placeholder can be used together, provided that the
wildcard 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 and
the placeholder, would add elements with names of any length that have
U as the first character, any one character as the second character, and D
as 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 management
tasks from inventory management and change control to configuration and
release management. These facilities are further enhanced through
comprehensive change administration, parallel development management,
software security and software information management facilities. As a
fully-integrated, single-vendor solution, Endevor dramatically improves the
operation and administration of IBM mainframe installations by providing:
A comprehensive inventory of all programs and software assets that reside
in partitioned data sets (PDSs), library management systems, HFS
directories, and executable libraries
An absolute history of all changes that have occurred to the source
Control of the processes and procedures that translate source into
executableforms
An inviolate and auditable link between the source code and its related
executable forms
Protection and control of inventory items through extended security
Automated cross-referencing of software component relationships for
purposes of historical analysis, change impact analysis, recreation of prior
versions, and release management
Control and automation of the movement and distribution of software
release packages from stage to stage, site to site, and across networks
Endevor accommodates the diversity of both small-scale and large-scale IS
operations. 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 always
changing. Today's applications have graduated beyond standard source to
include a wide variety of componentsmost outstripping traditional
80-character storage limitations. In addition to the changing complexion of the
inventory's physical structure, there is a growing proliferation of physical
libraries and functional environments (Test, QA, Production, and so on).
Programmers and IS support personnel typically require intimate knowledge
of those library structures as they relate logically to business units within an
organization. This logical view, divorced from the physical storage structure, is
required both to ensure that logically related inventory elements are being
manipulated consistently and correctly, and to provide a common user
interface regardless of physical structures. An effective inventory management
structure also forms the foundation for change control, configuration
management, and release management activities.
2.1.1 Automated Inventory Manager

Traditional software classification systems (PDSs, library management systems,
and so forth) provide limited inventory classification capabilities and highly
restrictive methods for storing and recreating prior versions of software
modules. When using these traditional systems, IS departments resort to
complex naming conventions and physical separate libraries to obtain a
semblance of organization. This indirect naming and storage technique is both
error-prone and inflexible. Consequently, as programmers move from project
team to project team, they are forced to learn and relearn the peculiarities of
manipulating the software inventory as applied by each project team. Clearly,
a common technique is required for classifying software throughout the IS
organization, one that provides both consistency and flexibility.
2.1.1.1 Logical Structure

Endevor employs advanced classification techniques that form the necessary
foundation for categorizing, viewing, and manipulating the application
software inventory in a consistent manner. An inventory item (element) is
identified to Endevor's Inventory manager by a fully-qualified name consisting
of its environment, stage (location), system, subsystem, type, and element
name.
Environment, Stage-As an application is modified and its elements are moved
throughout the software development life cycle, those elements may reside in
different functional locations (Test, QA, Production, Backup, and so on) at
different times. Within Endevor's inventory classification scheme, the location
of an element is part of the identification of that element.
System-Systems represent the logical grouping of inventory elements as they

apply to major applications, departments, or work areas within an
organization. Typically, a system is the "organizational owner" of a portion of
the inventory. For example, the systems in an organization might include
Finance, Personnel, and Manufacturing.
Subsystem-Subsystems are logical sub-classifications within systems. For
example, the Finance system might be divided into logical subsystems such as
General Ledger, Accounts Receivable, Accounts Payable, Common Routines,
and Reports.
Type-Within the application inventory, types represent the form of the
element, indicating how the element is created (the source language used) and
how it is manipulated. For example, the Finance system might have several
types of elements, including COBOL programs, Assembler programs, C
programs, PL/I programs, copy members, Assembler macros, screen
definitions, and linkage editor statements.
Element Name-The element name is the existing name of the element, because
it is already established. This logical classification scheme, as illustrated in the
following diagram, provides a consistent view of the inventory without
requiring the user to understand the inner workings of the inventory's physical
structure.
In Endevor, the logical attributes, which are used to classify an element,

include its location, system, subsystem, and type. These attributes are a direct
part of the identification of that element. This eliminates the need to establish
additional libraries, rename elements, or use cryptic naming conventions to
define and maintain a classification scheme. Because these classification
attributes are used in addition to the existing element name, there is no need
to rename elements to bring them under the control of the Endevor Inventory
Manager.
2.1.1.2 Physical Structure

In today's IT environment, the physical requirements of a properly managed
inventory have grown beyond the capabilities of older library management
systems and conventional PDS-based systems. Many library management
systems are unable to store source that is longer than 80 characters, despite the
fact that many modern-day languages do not conform to this format.
Conventional PDSs do not restrict record length, but elements of different
record lengths must reside in physically separate libraries. Using these
structures, the only way to keep multiple revisions of an element is to either
replicate libraries to hold prior revisions or use a naming convention in which
the revision is part of the element name.
Physical repository-Endevor's Inventory Manager has the flexibility to manage
the physical data sets in which elements are stored, without regard to logical
classification boundaries or trivial physical differences between the inventory
element
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 of
differences in logical classification
Change the underlying physical library structure without affecting the
logical view of the inventory
Base/Delta-Endevor employs advanced base/delta technology to store the

elements within the application inventory. The first time an element is added
into Endevor, it is stored in its entirety as the base. Subsequent updates to that
element create records containing only the changes to the element. These deltas
are automatically assigned level numbers and stored by Endevor as shown in
the following illustration.
This method yields substantial savings in storage overhead by providing an

efficient means of storing multiple revisions of an element. It also provides a
wide variety of ways to view change information, including current, historical
or changes only, available online or in hardcopy format. All change displays
identify what changes were made and by whom, when and why. This is
known 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 to
recreate 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 write
directly to AllFusion CA-Panvalet and AllFusion CA-Librarian files.
Additionally, these interfaces allow you to use AllFusion CA-Panvalet and
AllFusion CA-Librarian files to contain base/delta source within Endevor. In
this way, your initial investment in library management systems is enhanced
rather than rendered obsolete.
2.2 Change Control
2.2 Change Control

Applications typically undergo extensive modifications as companies
customize and fine-tune software systems to meet their specific business
requirements. Given the sheer volume of change requests in today's IT
organization and the growing demand for more effective ways of tracking and
documenting development change activity, manual change control procedures
can no longer be relied upon to produce the accurate, reliable information
needed to identify problems, track projects, and analyze the impact of change.
2.2.1 Automated Change Control

Endevor forms an envelope around your application environment and captures
all change events, enabling you to identify what has been changed, who made
the changes, when, and why. And since Endevor performs change control
functions automatically, the resulting information is always accurate and
up-to-date.
2.2.1.1 Identifying and Tracking Changes

As a prerequisite to understanding, controlling, and auditing the software
environment, change control systems must be able to identify changes as they
occur, then further pinpoint when the changes were made, by whom, when,
and why.
CCIDs-Endevor Change Control Identifiers (CCIDs) provide a means of
grouping and manipulating similar kinds of change activity. For example, a
number of different elements (COBOL copy members, COBOL programs, and
so forth) can be included in a single change request. By tagging each of those
changes with a common CCID (such as FIX01), every change made for that
change request is categorized as belonging to that CCID. Subsequently, the
CCID can be used to identify and manipulate all the elements within the
change request. For example: Move all elements for COD FIX01 from Unit Test
to System Test. CCIDs can also be predefined and validated for change
administration purposes.
Change History-Endevor automatically captures and dynamically tracks all
source changes by creating a unique delta to record each change event. An
element's delta levels identify not only the actual lines of code that have been
changed, but also user, comment, CCID, and date and time information for
that change. The result is a complete and accurate history or audit trail of
application change activity.
2.2 Change Control
Regression Notification-In parallel development situations where many

individuals work on the same module concurrently, change regression occurs
when one individual unintentionally negates (rather than incorporates) the
changes made by another individual. When unchecked, regression can be a
major cause of production failures. During action processing, Endevor
performs a regression check and notifies you when regression has occurred,
allowing you to quickly pinpoint and correct the situation before it adversely
affects the production environment.
Signin, Signout-In order to avoid possible regression during parallel
development, Endevor provides signin/signout security at the element level.
This optional capability is enabled on a system-by-system basis. When the
facility is enabled, elements are signed out as they are retrieved. While other
users can retrieve copies of those signed out elements, they cannot update
those copies within Endevor without explicitly overriding the original user's
signout. Only authorized users can exercise the explicit override feature.
Activity Logging-A complete log of all activity within Endevor can be written
to a variety of data structures, including standard SMF records. This
information, available online and in hardcopy format, provides a high level
audit trail of change events which can be used to determine change patterns
over time.
2.2.1.2 AllFusion Endevor Change Manager Interface for IBM's Tivoli Information
Manager
Endevor provides a flexible, programmable interface to IBM's Tivoli
Information Manager change management product. This interface allows
certain change administration functions to be performed through Tivoli
Information Manager on behalf of Endevor. These functions include: the
validation of CCIDs against the Tivoli Information Manager database; the
logging of Endevor actions to Tivoli Information Manager; the ability to use
Tivoli Information Manager's approval and notification facilities; the ability to
control Endevor actions based on Tivoli Information Manager's CCID status
information; and the ability to query and utilize Tivoli Information Manager's
change, problem, and configuration information during Endevor action
processing.
2.2.1.3 Automating Processes

In application development, a procedure or process is the set of steps used to
transform source language statements into executable code. Some inventory
elements, such as those written in 3rd generation languages (COBOL,
Assembler, C, PL/I, and so on) have straightforward processes that compile
the source and link-edit the object. Other element types require more complex
processes, such as the resolution of data base calls or the automated generation
of textual documents. Because these processes ultimately determine how an
element will interact in production, the management of these procedures is
critical.
2.2 Change Control
One of the powerful facilities provided by Endevor involves the regulation and
control of all transformation processes through automated procedures called
processors. Endevor processors are written in job control language (JCL)
statements that specify process steps, parameters, error conditions, data set
names, output libraries and the like. Once defined, processors can be used to
automatically carry out a variety of procedures and create the outputs
associated with application elements. Element types within the inventory
classification determine the appropriate processors. For instance, elements that
are written in COBOL are typically handled by the COBOL compiler and
linkage editor, while elements that are classified as copy members are usually
validated and copied to a specific location.
Automated Output Generation-Endevor processors are often used to automate
the procedures that generate outputs from source. As illustrated in the
following diagram, you can create a processor for Batch COBOL programs that
automatically performs a COBOL compile and link-edit into the Finance
system's load library, and stores the listing in the Finance system's listing
library.
2.2 Change Control
Automated Promotion Procedures-A processor can also contain procedures for

promoting applications throughout the development life cycle. When Endevor
is instructed to perform a promotion, it reads the processor definition to obtain
directions about the promotion procedures specified for a selected element
type. Those procedures are then uniformly invoked by Endevor. When
promoting a Batch COBOL program within the Finance system from Testing to
Production, for example, a MOVE processor can be defined which contains
instructions for automatically copying the load modules from the Test load
library to the Production load library.
Automated Backup and Recovery-In addition to automating the procedures
used to generate outputs from source and promote applications throughout the
development life cycle, processors can be defined to execute emergency backup
and recovery procedures. For example, a MOVE processor can contain a step
that automatically copies production load modules to a backup library. A
recovery procedure can additionally be defined to copy that module from the
backup 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, you
must be able to link executable code back to its originating source. Endevor
achieves this goal by controlling the processes by which outputs are created
from the source, and further ensures source-to-executable synchronization by
audit stamping or footprinting those outputs.
Process Control-Endevor's automated processors ensure that the
source-to-executable link is not compromised, by tying the process used to
create outputs directly to the manipulation of the source. Frequently, load
modules and their associated source are processed at different points in time,
presenting a precarious window in which a change to either one causes an
out-of-sync condition. When source is presented to Endevor, the outputs are
automatically created from the current source through the use of automated
processors. When source is moved through the development life cycle,
Endevor's automated processors ensure that the load modules and outputs are
manipulated together with the source, rather than through separate
procedures.
Footprints-Footprinting is a change control technique employed by Endevor to
maintain synchronization between source and its related executable. During
element processing, Endevor places an encrypted audit stamp called a
footprint in the output source, object, or load modules that are created. Only
Endevor automatically builds footprints as an integral part of the
source-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 a
PDS, 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 a
comment field; in a load module, in the user IDR record for the CSECT. All
data structures managed by Endevor (source libraries, copy libraries,
executable libraries, and processor listing libraries) contain footprinted
elements. Footprints can be used to validate the source-to-executable link of
an entire load library. And because Endevor footprints uniquely identify the
versions/levels of input components, they play a key role in configuration
management. The following diagram provides a high-level view of how
automated processors and footprints work together.
2.2 Change Control
As illustrated previously: 1) the source is built from Endevor's internal

base/delta format, and a footprint representing that element's source is created
and made available to subsequent steps in the Endevor processor; 2) the source
is compiled; 3) the output object from the compile is stamped with a footprint
before being passed to the next step; 4) the linkage editor links the program
into the appropriate load library; and 5) the listings from the previous steps
are combined and stored (also with a footprint) in the appropriate listing
library.
2.2.1.5 Audit Management

As valuable corporate assets, applications cannot be compromised when it
comes to integrity, reliability, and recoverability. For this reason, applications
must be controlled and secured in a way that meets stringent auditability
requirements. Endevor's automated change control functionality fully satisfies
the scope of an audit and provides the necessary platform for producing
management reports that can be used to evaluate software integrity.
2.2.2 Endevor Actions

Endevor performs software management operations through user-invoked
actions, 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 history
and 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 for
an element.
LIST-The action used to scan members in a library or the Endevor inventory
to generate a list of elements that meet specific selection criteria.
MOVE-The action used to promote an element from stage to stage within an
Endevor 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 an
archived data set.
2.2 Change Control
RETRIEVE-The action used to copy any level of the source of an element from
an Endevor environment into an external data set.
SIGNIN-The action used to remove the user signout associated with an
element.
TRANSFER-The action used to transport an element from one location to
another, where each location can be either an Endevor location or an external
data set.
UPDATE-The action used to create a revision of an element in an Endevor
environment. When applicable, these actions drive the automated processors
that have been defined to Endevor. Before an action is executed by Endevor, a
security check confirms the user's authority to perform that action upon the
requested element. All actions and their results are reflected in Endevor
execution 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 software
inventory are time-consuming and prone to error. Endevor's Software Control
Language (SCL) is a powerful yet simple language which, when combined
with Endevor actions, eases the burden of manipulating and moving portions
of the software inventory throughout the entire development life cycle.
2.2.3.1 SCL Capabilities

SCL saves substantial amounts of time by enabling you to work with as many
(or as few) Endevor actions as are required to complete a specific job. With
SCL, you can:
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 sorting
elements 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 use
separate utilities to scan source code.
For problem-solving purposes, generate a list of only those elements that
were 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 an

easy-to-use, flexible environment for executing software procedures. Using
SCL, repetitive tasks, which normally require significant amounts of time, can
be accomplished with very little effort.

Historically, a major deficiency in the management of software systems has
been the lack of an accurate means of determining the interdependencies or
configurations of applications and their related components. Semi-automated
source scanning techniques have provided a partial solution. These techniques
are no longer feasible, however, given the size and complexity of today's
applications, the frequency of component changes, and the growing demand
for a more auditable means of tracking and managing software configurations
as they evolve over time.
2.3.1 AllFusion Endevor Change Manager Automated Configuration

Option
Built upon a logical inventory structure and a powerful change control
platform, 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 its
related components are collected from their resident libraries (copylibs,
maclibs, and so forth). In order to keep an accurate record of changing
software configurations, the process of tracking program-component
relationships and associated change activity must be performed automatically
as an integral part of the translation procedure.
The Component Monitor-While a program or module is being translated by a

processor, ACM automatically captures the program-component relationships
as they are resolved from the selected data sets, as the illustration shows:
The Component List-As output from the translation procedure, ACM

automatically produces a snapshot or Component List for each monitored
program. This Component List is an internal data structure that preserves a
physical profile of the configuration. As illustrated following, the Component
List identifies all input program components and where they originated, as
well as the output components created as the result of the translation
procedure. Footprint information, including the version and level of the
component, is also noted, if present.
Configuration
Type
Name
Footprint
Information
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. The

processor information describes the Endevor processor used to generate the
element. The input components identify the component items referenced and
any footprints that exist in the monitored data set. The output components
identify the elements that were created during processor execution.
Storing Component Lists-The first time a Component List is created, it is
stored in its entirety as the base. Subsequent differences in Component Lists
from one program translation to the next are stored as deltas (changes only)
and automatically assigned a component level number. By using base/delta
technology to store Component Lists, ACM enables you to compare
component changes from compile to compile, a capability unavailable through
source scanning techniques.
Viewing Component Lists-When stored over time, Component List
information becomes the basis for maintaining and viewing component history.
Through online displays, ACM lets you view Component List information
from four perspectives: 1) summary of component levels, 2) current level of a
component, 3) component changes, and 4) component history.
2.3.1.2 Using Software Configurations

Using the information contained within Component Lists, it is possible to
create a selection list. In the diagram below, a selection list has been created by
using Endevor to LIST all programs WHERE COMPONENTS EQUAL
'COPYRECA.'
As a powerful cross-reference facility, the LIST action, in combination with

selection lists in SCL format, provides the necessary foundation for performing
a number of essential configuration management functions.
Propagating Component Changes to Related Programs- When a component is
changed, it is necessary to propagate those changes to all affected programs.
Using the LIST action, you can perform change impact analysis by identifying
every program containing that changed component. And you can also use the
resulting selection list to perform bulk data manipulation by re-compiling
those programs, all at the same time, to reflect the change.
Validating a System for Consistent Use of Components - In order to prevent
production failures, it is desirable to validate that all programs are using the
correct component versions/levels. Execution reports from LIST action
execution, in combination with selection lists, can be used to identify
inconsistencies.
Re-Creating Past Configurations-It is sometimes necessary to recreate a

program 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 that
includes the old versions/levels of all related components used at the
date/time the load module was originally created.

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

Release management activities revolve around identifying and distributing
software releases. Depending on the circumstances, a "release" can consist of
the elements changed during a maintenance effort, or it can represent an entire
cross-section of the software inventory. Distribution of a release can be as
simple as promoting a change into production, or as complicated as managing
multiple concurrent releases of entire software systems. Accurate and
up-to-date information is a prerequisite for performing every task, from
creating a list of exactly what is to be released to verifying that the release was
successfully accomplished. This kind of information can only be obtained
through an automated, integrated release management system.
2.5.1 Automated Release Management

In many installations, production turnover and release management are
performed, often manually, as discrete activities by separate groups. Problems
arise when software release packages are created manually "on paper," where
there is a chance that the contents are incomplete or inadvertently changed
prior to or during execution. Endevor provides integrated, automated release
management functionality, ensuring that software release packages are built on
a 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 package
approval capabilities. Only with these combined capabilities is it possible to
accurately create and manipulate a software release, perform change impact
analyses, and track changes from release to release.
2.5.1.1 Change Administration

Endevor provides change administration, in addition to security, as a means of
specifically organizing and controlling change to portions of the software
inventory. Through the Endevor change administration facilities, it is possible
to provide authorization capabilities to the person(s) responsible for portions of
the software inventory.
Approver Groups-Endevor establishes change administration authorization
through the definition of approver groups (named groups of user IDs) and the
subsequent relation of those approver groups to portions of the Endevor
inventory. For example, within the Payroll subsystem of the Finance system,
you could establish an approver group that approves or denies changes to all
elements within that system and subsystem. Some of the users within the
group could be required to approve changes while the approval of other users
would be optional. A quorum or minimum required number of approvers can
be established for any approver group. "EMERGENCY" approver groups can
be established consisting of those user IDs which must authorize emergency
fixes to a portion of the inventory.
Change Packages-Authorized users build change packages, which contain

Endevor action requests. The user specifies whether the handling of that
change package will be defined as 'STANDARD' or 'EMERGENCY'. The user
also defines a date/time window within which the change package can be
executed. Once the change package is built, it is then CAST, a process which
causes Endevor to prepare the package for subsequent approval processing.
Endevor automatically builds the list of approvers for a change package based
on the previously defined approver groups. The change package then goes
through approval processing, followed eventually by execution.
2.5.1.2 How It Works

Building a Change Package-Authorized users build change packages
consisting of any number of Endevor action requests. Change packages can be
built from online screens, imported from outside data sets and/or copied from
existing packages. They can be edited, modified and/or appended to at any
point during the build process.
Preparing a Change Package for Review-The change package is CAST. The
process of casting a change package causes the approvers for that package to
be built based on the previously defined approver groups. Once a package is
CAST, it can no longer be modified.
Reviewing a Change Package-Users in the approver group(s) associated with
a package can approve or deny the change package. Required users must
provide their approval. Once all required approvals have been made, and the
established quorum of approvals has been met, the change package can be
executed.
Executing a Change Package-At execution time, Endevor validates that all
approvals have been made and that none of the elements have changed
between the time the change package was CAST and when it was executed.
Endevor also validates that the change package is being executed within the
date/time window established when the change package was built. Endevor
then executes all of the actions in the change package. Checkpoint/restart
facilities are available so that change packages that fail execution can be
re-executed properly. Change packages can be executed online or in batch.
Automatic Package Backout-Subsequent to execution, it is possible to quickly
and easily back out a change package. BACKOUT has the effect of reversing
any outputs created by the execution of that package to the state they were in
prior to package execution. BACKIN reverses the process.
2.5.1.3 Managing Production Turnover

Using the Component Lists created by Endevor's Automated Configuration
Manager in combination with Endevor's logical inventory structure, you can
build a change package containing all of the programs and components that
make up a maintenance release. Once the package has been built, it can be
used 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 maintenance
release, those CCIDs can be used as selection criteria to produce a package that
itemizes all of the elements which comprise that maintenance release, as well
as all related element components. For example, you could build a package
that 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 been
constructed and has gone through the appropriate approvals, it can be used to
perform the production turnover. In our example, execution of the ' FIX01'
change package will automatically perform production turnover, promoting all
of the elements contained in the package.
2.5.1.4 Managing Software Releases

Endevor's powerful inventory structure, together with ACM's Component
Lists, can be used to manage all aspects of releasing software . Once a change
package has been generated, its contents can be used to drive the distribution
of the software release, track changes from release to release, and recreate
previous releases.
Creating a Software Release Package-The inventory management structure of

Endevor and the configuration information created by ACM can be used to
create complete, reliable, and reusable software release packages. For example,
a complete release package could be built containing all of the elements in
Release 2 of the Finance system, and all of the components belonging to those
elements. The resulting package would contain not only all of the elements
that comprise the software release at this point in time, but information about
the current versions and levels of those elements.
Release Distribution-Once a release package has been constructed, it can be
used to drive the distribution process, regardless of whether the software is to
be moved to another Endevor location in-house, transferred to another
Endevor location at a remote machine or site, or distributed to external files,
perhaps for shipping to customers or divisions. In our example, the contents of
the package created previously are used to drive the TRANSFER of Release 2
of the Finance system from Site 1 to Site 2:
Using the contents of release packages to drive the distribution process

provides the added advantage of automating both the distribution process and
the 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 to
track changes from release to release. This broad, system-wide perspective is
necessary when managing multiple software releases. Packages are kept in
such 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 release
to the next. If the contents of the package are extracted and stored in Endevor's
base/delta format, it is also possible to view changes to a software system over
time. This capability is especially useful when trying to identify which
modules of a software system have been added, removed, or changed prior to
distributing a partial release consisting of changed components only.
2.6 Supporting Functionality

In addition to its inventory management, change control, configuration
management, and release management facilities, Endevor provides capabilities
in the areas of parallel development management, software security
management, and software information management. This broad range of
product functionality is designed to support the entire software management
life cycle, not just one aspect.
2.6.1 AllFusion Endevor Change Manager Parallel Development

Option
Endevor provides parallel development management capabilities through the
AllFusion Endevor Change Manager Parallel Development Option (PDM).
Using this powerful development tool, it is possible to create a merged
program from the comparison of a base program and two independently
modified versions of that base program. By eliminating many of the
time-consuming, manual tasks associated with merging parallel development
updates, PDM saves time and reduces the margin for error. PDM also provides
a means of identifying and resolving conflicts before merging program
updates. For this reason, PDM is a necessary tool for effectively managing
concurrent application development and resolving problems which arise when
integrating in-house modifications with vendor updates.
2.6.1.1 Managing Parallel Development Activities

When several programmers work on the same module concurrently, there is
always the danger that some modifications will be overridden by others or will
be in direct conflict with one another. Beyond the basic frustration factor, this
problem can have serious consequences from a control and maintenance
standpoint.
2.6.1.2 Managing Vendor Updates

Purchased software packages are typically customized to meet in-house
demands. Unless those modifications are painstakingly documented, problems
arise when an update arrives from the vendor. What exactly was changed
in-house? And what modules did the vendor change, add, or delete? Manual
methods for resolving these conflicts are time-consuming and error-prone,
underlining the need for automated solutions for merging vendor updates with
in-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 Development
Manager is to build a Work-in-Process (WIP) file. The WIP file is a PDS
structure which combines three source files: the Root, Derivation 1, and
Derivation 2. As an example, if PDM is being used to manage a vendor
update, the Root would be the source for the old release, Derivation 1 would
be the source for the in-house modifications made to that old release, and
Derivation 2 would be the source for the vendor's new release. As the source
input files are being compared to produce a WIP File, statistics are generated.
These statistics reveal critical information about the source comparison, such as
the number of inserts and deletes per module, the percentage of the module
that 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 and
edit the members which contain conflicts. At this point, you can decide which
conflicts to resolve and how to resolve them.
Creating Merged Source-Once you have viewed and edited the WIP file to
your satisfaction, you can use PDM to automatically merge the WIP source
into an output source library. This output source is then ready for compilation
or, if applicable, introduction into Endevor. The Parallel Development
Manager can be used in both online and batch modes, and can operate on a
member-by-member basis on a list of members, or on any portion of the
Endevor inventory.
2.6.2 Software Security Management

Traditionally, inventory security has been provided at the physical file level
but not at the individual element level. Endevor security is based on its
inventory structure, enabling security rules to be defined according to that
structure, at the system, subsystem, type, and element levels. Additionally,
Endevor actions are secured, providing a means of restricting individuals to
the appropriate change control functions at specific stages within the software
development life cycle.
2.6.2.1 Native Security

Endevor native security provides protection against unauthorized access and
processing through three tables: Access Security, User Security, and Resource
Security. The Access Security Table defines the environments to which each
user has access. The User Security Table defines the systems/subsystems
within a particular environment and the level of activity for which each user is
permitted access (display only, delete, add, and so on). The Resource Security
Table defines any element naming conventions that are restricted to a
particular system/subsystem and the Endevor actions for which the restriction
applies. The use of Endevor native security is optional and is enabled only if
one or more of these tables is defined. When defined, access is permitted only
through these tables.
2.6.2.2 AllFusion Endevor Change Manager Interface for External Security

In addition to native security, Endevor provides the AllFusion Endevor
Change Manager Interface for External Security (Endevor ESI). With Endevor
ESI, installations which currently use eTrust CA-ACF2 Security, eTrust CA-Top
Secret Security, or RACF security systems can secure access to Endevor
functions and data sets through those centralized systems rather than locally
through Endevor security tables. Endevor ESI accomplishes this through an
interface to IBM's System Authorization Facility (SAF). As illustrated in the
following diagram, Endevor ESI replaces standard Endevor security tables with
an SAF interface module.
With Endevor ESI in place, each security request is checked through the
centralized security system in order to validate access to Endevor
environments, menu options, and actions against inventory elements.
2.6.3 Software Information Management

Through a combination of its master inventory data base (Master Control File)
and SMF log file, which notes every change attempted and completed, as well
as security violation information, Endevor provides extensive display and
reporting facilities. The resulting information provides managers with an
accurate 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 change
information online. The following displays can also be printed in hardcopy
format:
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 of
systems, subsystems, element types, and elements, as specified to the Endevor
Master 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 and

element activity as recorded by Endevor:
Security Violation Profile
Security Violation Summary
Element Activity Profile
Element Activity Summary
Footprint Reports-The following reports document footprint information
placed 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 change
package activity:
Package Detail Reports
Package Summary Report
2.6.4 Endevor Benefit Summary

Based on advanced change control technology which is implemented through
an automated, integrated approach, Endevor yields a number of substantial
benefits by:
Providing extensive inventory management capabilities which
accommodate all source and executable code, regardless of type or record
length.
Providing a means of categorizing, viewing and manipulating physical
inventory components as they relate to logical workgroups.
Creating an unbreakable audit trail of all change events for purposes of
historical 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 originating
source.
Enforcing standard, consistent change processes.
Providing an accurate means of creating and tracking software
configurations.
Automating the movement of entire software release packages throughout
the development life cycle.
Providing additional approval and notification capabilities through change

administration functionality.
Extending security to the inventory member level.
Providing a means to compare and implement vendor application updates.
Chapter 3. Defining Inventory Structures
Chapter 3. Defining Inventory Structures 3-1
3.1 Basic Panel Flow

3.1.1 Introduction
This section introduces the basic panels involved in displaying environment
and stage information, and defining and maintaining system, subsystem, and
type definitions. (If you want to perform these tasks in batch, see the
Environment Definition chapter in the SCL Reference Guide for the appropriate
SCL commands.)
1. Begin by invoking Endevor, as described in the User Guide. If you have
access to multiple environments, Endevor first displays the Environment
Selection panel.
------------------------ 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 OPTION
field, and pressing Enter. Endevor displays the AllFusion Endevor
AllFusion Endevor Primary Options Panel.
---------------- AllFusion Endevor Primary Options Panel ---------------------Option ===> 4

1
2
3
4
5
6
U
T
C
X
DEFAULTS
DISPLAY
FOREGROUND
BATCH
ENVIRONMENT
PACKAGE
BATCH PACKAGE
USER MENU
TUTORIAL
CHANGES
EXIT
Specify Endevor ISPF default parameters

Perform Display functions
Execute Foreground Actions
Perform Batch Action processing
Define or Modify Environment information
Perform Foreground Package processing
Perform Batch Package SCL Generation
Display user option menu
Display information about Endevor
Display summary of changes for this release of Endevor
Exit the Endevor dialog
Current environment: SMPLTEST

(C) 22 Computer Associates International, Inc.
Use the EXIT option to terminate Endevor
3. Select option 4 (ENVIRONMENT) on the AllFusion Endevor Primary

Options Panel, and press Enter. Endevor displays the Environment
Options Menu.
-----------------------OPTION
1
2
3
4
5
6
7
8
9
A
D
E
S
ENVIRONMENT OPTIONS MENU
---------------------------
===>
SITE
STAGE
SYSTEM
SUBSYSTEM
TYPE
PROCESSOR GROUP
TYPE SEQUENCE
DATA SET
APPROVER GROUP
RELATE GROUP
DESTINATION
ENVIRONMENT
SITE SYMBOLS
Display site information

Display stage information
Display, delete, create, update or clone system
Display, delete, create or update subsystem
Display, delete, create or update type definitions
Display, delete, create or update processor groups
Display or update type processing sequence
Display or update type data sets
Display, delete, create or update approver groups
Relate approver groups to systems, subsystems, etc.
Display, delete, create or update shipment destinations
Display information about the current environment
Display site symbol definitions
4. To select an option, type the appropriate number or letter (1-9, A, D, E, or

S ) in the Option field, press Enter. Endevor displays the subfunction
panel for the option requested.
5. When you are through, return to the AllFusion Endevor Primary Options
Panel by pressing END repeatedly. To return to the invoking facility (ISPF
or TSO) from the AllFusion Endevor Primary Options Panel, press End, or
type END in the Option field, and press Enter.
Note: This Environment Options Menu shows that the Global Type
Sequencing option is not in effect. If the Global Type Sequencing option is
enabled at your site, the description on the Environment Options Menu for
option 7 TYPE SEQUENCE appears differently than if it is not in effect. When
Global Type Sequencing is not in effect, type sequencing can be viewed and
updated through the Environment Options Menu. When Global Type
Sequencing is in effect, the Type Sequencing can be viewed, but not updated
through the Environment Options Menu. For details, see Global Type
Sequencing in the User Guide
3.1.2 The Environment Options Menu

The options for the Environment Options menu are summarized below.
Options 1-5, 7, 8, and E are discussed in more detail later in this chapter.
Option S is discussed in Chapter 7, Site Symbolics. Option 6 is covered in
the Extended Processors Guide. Options 9, A, and D, are discussed in the
Packages Guide.
Use this option
To
Display site definitions, as specified in the Endevor

Defaults Table.
Display the two stage definitions for an environment.
Display, delete, create, update, or clone (copy) the

definition and/or mapping of a system.
Display, delete, create, or update the definition

and/or mapping of a subsystem.

and/or mapping of a type.

and/or mapping of a processor group.
Display or update the relative sequence of execution

for Endevor actions, for all element types defined to a
particular system. If the optional feature Global Type
Sequencing is enabled at your site, you cannot update
the type processing sequence through the
Environment Options Menu.
Change the data sets defined for use with a specific

system.
Display, delete, create, or update approver groups.
Establish relationships between approver groups and

inventory areas within an environment.
Display, delete, create, or update destinations for

package shipments.
Display environment definitions, as specified in the

Endevor Defaults Table.
Display the site symbolics table. The table is

specified in the C1DEFLTS table.
3.1.3 Request and Selection Panels

Endevor 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 - 9
and A on the Environment Options Menu. Request panels look like this:
----------------------------OPTION
TYPE REQUEST
----------------------------------
===>
blank - Display
# - Delete type
C - Create type
U - Update type
type definition
definition
definition
definition
ENVIRONMENT ===> SMPLTEST

SYSTEM
===>
TYPE
===>
STAGE
===> T
T - TEST
Q - QA
You use these panels to request a particular function (display, delete, create, or
update), and to identify the particular system, subsystem, or type against
which you want to perform the function.
Selection List panels appear after request panels when you provide name
masks in any of the fields on the request panel. Selection List panels look like
this:
-------------------------COMMAND ===>
CURRENT ENV:
NEXT
ENV:
SYSTEM SELECTION LIST
----------- ROW 1 OF 2
SCROLL ===> CSR
SMPLTEST
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 for
display, update, or deletion. From this panel, you can display an item by
placing an S to the left of the listed name. On some selection panels, you can:
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 selection
list, Endevor displays the definition panel for the selected items, with the
requested mode (Display, Delete, or Update) in the upper left corner of the
panel.

3.2.1 Site Information Panel
To display information specific to the current site (as coded in the Defaults
Table), 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 4. BETA/2

------------------ Function Controls -------------------- Options Site ID...........
Access Table...... BC1TNEQU
ACM...... Y
Release........... B4C
SMF Record Number.
DB2...... N
Environments...... 2
Library System.... PV
QuickEdit Y
Userid Start...... 1
Library Program...
ELINK.... N
Userid Length..... 7
VIO Unit.......... SYSDA
ESI...... Y
Batch ID..........
Work Unit......... SYSDA
INFO..... N
SPFEDIT QNAME..... SPFEDIT
Work Volser.......
LIBENV... Y
SYSIEWL QNAME..... SYSIEWLP
Lines per Page.... 6
NETMAN... N
Authorized Tables. REQUIRED
MODHLI............
PDM...... Y
Gen in place/SO... N
Signout on fetch.. Y
PROC..... Y
CA-L-SERV JRNL SBS.
ELINK XLTE TBL....
PITR Journal Grp..
Mixed Format...... CCID COMMENT DESCRIPTION
SYMBOLICS Table... ESYMBOLS
(Press Enter for Next Panel)
-------------------------- Package Processing Options --------------------------

Approval Reqd....Y
CAST Security.....N
Foreground Exec..Y
Comp Validation...O
Generated High-lvl Index for Remote PKG JCL........ ENDEVOR
Security..ESI
------------------------------- 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 the
Environment Options Menu.
3.2.2 Site Information Panel Fields

This 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
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 for

ownership (that is, for signout and override signout
processing). This field is used when the USERID
BATCHID field is 0 (JOBNAME).
Userid Length
Length of the user ID that is compared for

ownership. This field is used with the USERID
START field when the USERID BATCHID field is 0
(JOBNAME).
Field
Description
Batch ID
Where the user ID associated with a batch job is

extracted:
0 From the JOBNAME; the user ID is checked
for validity using the userid start and length
parameters as established previously.
1 From the USER parameter specified on the
job card submitted with the job. If no USER
parameter is defined, you receive an error
message.
2 From the USER parameter if it is specified
on the jobcard or, if no USER parameter has been
specified, from the JOBNAME. The user ID is
validated using the user ID start and length
parameters as established above.
SPFEDIT QNAME
Queue name used when Endevor issues an enqueue

on a sequential or partitioned data set (not
RECFM=U), to prevent simultaneous update to that
data set. The data set may be a source library, object
library, or other user library. The resource name for
the enqueue is the data set name.
SYSIEWL QNAME
Queue name used when Endevor issues an enqueue

on a PDS defined with RECFM=U (for example, a
load library), to prevent simultaneous update to that
PDS. The resource name for the enqueue is the data
set name.
Authorized Tables
Indicates whether Endevor's security tables have to

be 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 to

perform a Generate in-place with or without signout.
Y An element is signed out to the user who
performs a Generate in-place action. This is the
default.
N An element retains its signout setting.
Endevor will not sign out an element to a user
who performs a Generate in-place action.
Field
Description
CA-L-Serv JRNL SBS
The subsystem name associated with the L-Serv

address space. This field must be specified if L-Serv
is used to control one or more Endevor control files
and the default L-Serv subsystem name is not used.
PITR Journal Grp
An L-Serv journal group ID that relates the package

data set named in this macro to a specific set of
L-Serv journal files. Specification of this parameter
enables journaling of changes to Master Control Files
and the Package Control File. The format is:
(gggg,nnnn)
Where:
gggg
The journal group ID associated with the package
journal files.
nnnn
The journal group subsystem ID. For more
information, see the Utilities Guide.
SYMBOLICS Table
Name of a load module containing the site symbol

definition 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 out

by 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 is

AllFusion CA-Librarian (LB). This entry indicates the
name of the AllFusion CA-Librarian load module for
your site.
VIO Unit
Symbolic device name for temporary disk data sets

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

that are not stored on a virtual I/O unit.
Work Volser
Volume serial number of the disk used to store

temporary data sets.
Lines per page
Number of lines printed per page, for reports

generated by Endevor.
Field
Description
MODHLI
Allows you to assign a prefix other than SYSyyddd to

a temporary data set, creating a pseudo-temporary
data set. This applies to temporary data sets that are
allocated DISP=MOD at any step in a processor only.
Regular temporary data sets, which are not
DISP=MOD, use the standard z/OS temporary data
set name. This prefix appears as the first node of the
data set name.
The value specified is a high-level qualifier, which all
Endevor 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:
modhli
The data specified in the MODHLI operand
yyddd
Julian date
hhmmss
Time in hours, minutes, and seconds
jobname
Same value as jobname
ddname
DDname specified in the processor
RA0 is used instead of RA000 to accommodate 8-byte
MODHLI and 8-byte DDnames.
If MODHLI is not specified in the Defaults Table, the
effective 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.
ELINK XLTE TBL
Defines the ELink translation tables.
Field
Description
Mixed Format
Indicates whether Endevor accepts mixed-case entries

in 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 additional
Endevor facilities (such as ACM or ESI) in use at your site at this time. These
fields are display-only fields.
Field
Description
ASCM
Indicates if the Endevor ACM facility is installed: Y

or N
DB2
Indicates if the Endevor for DB2 facility is installed: Y

or N
ELINK
Indicates if the Endevor Link is installed: Y or N
ESI
Indicates if the Endevor ESI facility is installed: Y or

N
INFO
Indicates if the Endevor Information/Management

Interface facility is installed: Y or N
LIBENV
Indicates if you have the ability to use AllFusion

CA-Librarian or AllFusion CA-Panvalet with
Endevor: Y or N
NETMAN
Indicates if the Endevor Netman Interface facility is

installed: Y or N
PDM
Indicates if the Endevor Parallel Development

Manager (PDM) facility is installed: Y or N
PROC
Indicates if you have the ability to run processors at

your site: Y or N
Note:
Y Yes
N No
3.2.2.4 Package Processing Fields

These fields are display-only fields.
Field
Description
ApprovalReqd
Indicates whether packages must be approved: Y or

N
Foreground Exec
Indicates whether packages may be executed in

foreground.
Generated High-lvl
Index for Remote
PKG JCL
The data set name used for remote package

shipments.
Cast Security
Indicates whether to check security authorizations for

every action in a package for the user ID requesting
package cast: Y or N
Comp Validation
Indicates whether component validation is enabled

for 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 package

options.
APPROVER The site is restricting package
actions to package approvers.
ESI The site is controlling package options
through an external security package such as
eTrust CA-ACF2, eTrust CA-Top Secret, or IBM
RACF using the ESI interface.
MIGRATE The site is in transition between
Approver security and ESI security. Both are
checked.
CAUTION:
The approver security rules supersede the ESI
security rules. If the user is granted access to the
package by the approver rules, ESI is not invoked.
ESI is invoked only when the user does not belong
to any approver groups associated with the package.
If there are no approver groups associated with the
package no access restrictions apply. This occurs
with ALL packages before they are CAST.
Note:
Y Yes
N No
3.2.2.5 Control Data Set Names Fields

The following fields are display-only fields.
Field
Description
Element Catalog
Name of the file containing the element catalog. For

more information, see 1.4, Endevor Libraries on
page 1-15.
Package Control File
Identifies the data set used in this environment to

store packages.
Endevor Macro
Library
Data set name of the source library established for

this site during installation. This is the library that
contains the Endevor macros.
CCID Validation
Data Set
Data set name of the sequential file containing the

definitions of the valid CCIDs established for this
site. This field is blank if CCID validation is not in
use.
Field
Description
ACM Query Root

Data Set
The name of the VSAM file your site uses to store the
name of each Endevor element and all its related
components. The recommended name is
uprfx.uqual.ACMROOT.
ACM Query Xref

Data Set
The name of the VSAM file your site uses to store the
name of each Endevor component relationship. The
recommended name is uprfx.uqual.ACMROOT.
3.2.2.6 Endevor Parmlib Information

Field
Description
Endevor Parmlib
Data Set
Data set name of the library, which contains the Type

Sequence Member.
Type Sequence Mbr
The name of the file that defines the processing order

for Global Type Sequencing.
3.2.2.7 CA-7 Data Set Name Fields

Field
Description
CA-7 Region CCI

Nodename
CCI Nodename assigned to the CA-7 address space.
JCL Data Set Index

Number
Sequence number associated with the CA-7

DEMAND JCL library.
JCL Data Set Index

Symbol
Symbol associated with the CA-7 DEMAND JCL

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

3.3.1 Stage Information Panel
To display the definitions of the two stages for the current environment, select
option 2 on the Environment Options Menu and press Enter. Endevor
displays a Stage Information panel. Use this panel to review the stage
definitions and, optionally, to request a display of the stage definitions for
another environment.
----------------------------- STAGE INFORMATION ------------------------------COMMAND ===>

CURRENT ENV ===> SMPLTEST
NEXT
ENV:
SMPLPROD
STAGE ID: P
STAGE 1 INFORMATION:
ID:
Name:
Title:
MCF data set name:
Entry Stage: N
T
TEST
UNIT TEST
CA.ENDEVOR.SMPLTEST.MCF
STAGE 2 INFORMATION:
ID:
Name:
Title:
MCF data set name:
Q
QA
QUALITY ASSURANCE
CA.ENDEVOR.SMPLQA.MCF
Entry Stage: Y
When you finish viewing the Stage Information display, either fill in the name
of a different environment (and press Enter) to view the stage definitions for
that environment, or press End to return to the Environment Options Menu.
3.3.2 Stage Information Panel Fields

Field
Description
Current Env
Name of the environment for which the stage

definitions are shown. Fill in a new name, and press
Enter to display the stage definitions for another
environment.
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:
Stage 2 Information
1
Stage 2 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.
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

3.4.1 System Request Panel
To define a new system, select option 3 on the Environment Options Menu,
and press Enter. Endevor displays the System Request panel.
---------------------------OPTION ===> k
SYSTEM REQUEST
---------------------------------
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 System

From the System Request panel, follow this procedure to define a new system
or access an existing system:
1. Select option C or K to create a new system. For information about option
K, see 3.5, Cloning System, Subsystem, and Type Definitions on
page 3-25.
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, press
Enter, 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 the
following section.
3.4.3 System Definition Panel

UPDATE
-------------------- SYSTEM DEFINITION -------------------------------COMMAND ===>
CURRENT ENV: SMPLTEST

NEXT
ENV:
SMPLPROD
SYSTEM:
ADMIN
NEXT SYSTEM ===> ADMIN
SYSTEM TITLE ===> ENDEVOR ADMINISTRATOR APPLICATIONS
UPDATED:
15OCT2 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:
ACTIVATE OPTION
===> Y (Y/N)
VALIDATE DATA SET
===> N (Y/N)
PROCESSOR TRANSLATION OUTPUT
STAGE 1 LOAD LIBRARY ===>
STAGE 1 LIST LIBRARY ===>
LAST SYSTEM BACKUP:

DATE:
22MAR4
TIME:
6:3
LIBRARIES:
CA.ENDEVOR.SMPLEMER.PRCSLOAD
CA.ENDEVOR.SMPLEMER.PRCSLIST
CA.ENDEVOR.SMPLPROD.PRCSLOAD
CA.ENDEVOR.SMPLPROD.PRCSLIST
Note: A different panel, specific to clone processing, is returned if you request

clone processing. For more information on this panel, see 3.5, Cloning
System, Subsystem, and Type Definitions on page 3-25.
3.4.4 Using the System Definition Panel

The use of the System Definition panel varies by processing option.
With this option
Use this panel to...
Display
Display the system definition.
Delete
View the system definition and verify that you want

to delete it. Press End if you want to cancel the
delete request.
Create
Define a new system.
Update
Change an existing system definition.
Once you have entered the necessary information on the panel, press Enter to
perform the requested processing.
3.4.5 System Definition Panel Fields

3.4.5.1 Identification Fields

The first three fields on the System Definition panel identify the environment.
Field
Description
Current Env 1
Name of the current environment.
Next Env 1
System 1
Name of the current system.
Next System
Name of this system in the next environment. You

can enter or change the name in this field when you
access 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 the

last user to update the system. When creating a new
system definition this field is blank.
Note:
Note: If you are planning to change system names across your map and to
use package component validation, see the Packages Guide for information
about the potential impact of these name changes on package component
validation functions.
3.4.5.2 General Options Fields

Field
Description
Comment
Indicates whether there must be a comment for

actions 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 actions

against 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 specify

ACKNOWLEDGE ELM JUMP=Y on the Move panel
when jumping elements. Acceptable values are:
Y User must specify ACKNOWLEDGE ELM
JUMP=Y.
N Default. User does not have to specify
ACKNOWLEDGE ELM JUMP=Y.
Note: Jumping occurs when you move an element
from one stage to another on a map route, and a
version of the element exists at an intermediate stage
that 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 for
this system.
Field
Description
Duplicate Element
Name Check
Specifies if Endevor checks to see if the element name

is used in any other subsystems within the system.
Default value is N. Valid values are:
Y Endevor checks for the same element name
in all the subsystems associated with this system.
N Endevor does not check for the same
element name in the other subsystems.
Field
Description
Msg Severity Lvl
Specifies the error message severity level if Endevor

is checking for DUPLICATE ELEMENT NAMES
within the system. Valid values are:
C The same element name exists within
another subsystem under the same system; the
action is performed and a caution message is
issued.
W The same element name exists within
action is performed and a warning message is
issued.
E The same element name exists within
action is terminated and an error message is
issued.
This field must be blank if DUPLICATE ELEMENT
NAME CHECK is set to No.
Duplicate Proc O/P

Type Check
Specifies if Endevor should check for duplicate

element names with the same processor output type
at the system level. The default value is N.
Y Endevor checks for duplicate element names
with the same processor output type at the
system level.
N Endevor does not check for duplicate
element names with the same processor output
type at the system level.
Msg Severity Lvl
Processor output registration check message severity

level.
C The same element name and same output
type exist within the same system and different
type; the action is performed and a caution
message is issued.
W The same element name exists within
another system or subsystem; the action is
performed and a warning message is issued.
E The same element name and same output
type exist within the same system and different
type; the action is terminated and an error
message is issued.
Must be blank if the Duplicate Proc O/P Type Check
feature is set to N.
3.4.5.4 Signin/Signout Options Fields

These fields contain definitions of the signin/signout functions in effect for the
system.
Field
Description
Activate Option
Acceptable values are:

Y If the signin/signout facility is in use for
this system.
N If the signin/signout facility is not is use.
Note: If signin/signout is set to N, Endevor does
not allow the signin action, but the signout userid
field is updated. If you set this to Y, an ESMPTBL is
present, and an element signout is overridden,
Endevor searches the table for the user ID that the
element is signed out to. If a match is found, an
email is addressed to the signout user. If no match is
found, no email is sent.
For a description of this facility, see the User Guide.
Validate Data Set

Y If the data set validation facility is in use for
this system.
N If the data set validation facility is not in
use.
When an element is retrieved, a "retrieve to" data set
name (and member name if the data set is a library)
is placed in the element master record.
When an ADD or UPDATE action is performed
against an element, Endevor compares the "retrieve
to" data set name (and member name if applicable) to
the source input data set and member name specified
for the action.
If the data set (and member) names match, the
action continues.
If the names do not match, Endevor checks the
value in the override signout field. If this value
is:
Y The action fails.
N Processing continues.
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.
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 the
system.
Field
Description
Stage 1 Load Library
Name of the Stage 1 processor load library for this

system. This load library must be different from the
load library for Stage 2.
Stage 1 List Library
Name of the Stage 1 processor listing library for this

system. This listing library must be different from
the load library for Stage 2.
Stage 2 Load Library
Name of the Stage 2 processor load library for this

system. If this load library is the same as the load
library for Stage 1, Endevor issues a warning
message.
Stage 2 List Library
Name of the Stage 2 processor listing library for this

system. If this listing library is the same as the
listing library for Stage 1, Endevor issues a warning
message.
Note: To locate an element's processor, Endevor always searches the Stage 1

load library first followed by the Stage 2 load library. The search order is the
same, regardless of the element's location.
3.5 Cloning System, Subsystem, and Type Definitions

3.5.1 Overview
Option K (Clone system structures) on the System Request panel can be used
to clone (copy) system, subsystem, and type definitions within or across
environments.
This is a powerful feature when you plan to set up multiple environments
with the same inventory classifications. In this situation, you only need to
define 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, and
type definitions that it clones. For example, if a base/image library associated
with a type definition you want to clone was deleted, Endevor clones the type
definition with the invalid data set name.
3.5.2 Procedure: Cloning a New System

Follow this procedure to clone inventory definitions:
1. Access the System Request panel for an environment/system definition
you want to clone.
2. Type K in the COMMAND field, type the name of a new system in the
SYSTEM 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 panel
appears.
5. Repeat Steps 1-4 for each inventory definition that you want to clone.
3.5.3 System Definition Panel for Cloning

CLONE
TO INFORMATION:
ENVIRONMENT:
SMPLTEST
SYSTEM:
ADMIN
TITLE
===> Endevor Administrative Applications
FROM INFORMATION:
ENVIRONMENT ===> SMPLprod
SYSTEM
===> admin
GENERAL OPTIONS:
COPY SUBSYSTEMS
COPY TYPES
===> Y
===> Y
(Y/N)
(Y/N) (TYPES AND PROCESSOR GROUPS)
3.5.4 System Definition Panel Fields

3.5.4.1 To Information
These fields identify the environment and system for which inventory
definitions are cloned.
Field
Description
Environment 1
System 1
Name of the new system.
Title
Description of the new system.
Note:
3.5.4.2 From Information

These fields identify the environment and system from which inventory
definitions are cloned.
Field
Description
Environment
Name of the source environment. You can change

the environment name to clone a system definition
from another environment.
System
Name of the system that is cloned.
3.5.4.3 General Options

Use these fields to indicate whether or not to clone subsystem, type, and
processor group definitions for the named system.
Field
Description
Copy Subsystems

Y Default. Clone subsystem definitions.
N Do not clone subsystem definitions.
Copy Types

Y Default. Clone type and processor group
definitions.
N Do not clone type and processor group
definitions.
3.6 Defining Subsystems

3.6.1 Subsystem Request Panel
To display, create, delete, or update subsystems, select option 4 on the
Environment Options panel, and press Enter. Endevor displays the Subsystem
Request panel.
--------------------------OPTION ===> c
SUBSYSTEM REQUEST
-------------------------------
blank - Display subsystem definition

# - Delete subsystem definition
C - Create subsystem definition
U - Update subsystem definition
SYSTEM
===> ADMIN
SUBSYSTEM
===> Process
3.6.2 Procedure: Subsystems

From 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-25.
4. Press Enter.
Enter, 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 Definition
panel, then press Enter to save the changes.
3.6.3 Subsystem Definition Panel

Once you have entered the necessary information on the Subsystem Definition
panel, press Enter to perform the requested processing.
CREATE
------------------- SUBSYSTEM DEFINITION -----------------------------COMMAND ===>

CURRENT ENV:
NEXT
ENV:
SMPLTEST
SMPLTEST
SYSTEM TITLE:
SYSTEM:
SYSTEM:
ADMIN
ADMIN
Endevor Administration Systems
SUBSYSTEM:
PROCESS
TITLE
===> Administration of Endevor - Processors, Tools, etc
NEXT SUBSYSTEM ===> PROCESS
UPDATED:
BY
3.6.4 Using the Subsystem Definition Panel

The use of the Subsystem Definition panel varies by processing option.
With this option
Use this panel to
Display
Display the subsystem definition.
Delete
View a subsystem definition and verify that you want

to delete it. Press End if you want to cancel a delete
request.
Create
Define a new subsystem.
Update
Change an existing subsystem definition.
3.6.5 Subsystem Definition Panel Fields

Field
Description
Current Env
System
Next Env
System
Name of the next system on the map.
System Title
Descriptive title for the system.
Subsystem
Name of the subsystem being processed.
Field
Description
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 user

to update the subsystem. When creating a new
subsystem definition this field is blank.
CAUTION:
Type names cannot be changed across the map.
3.7 Defining Types
3.7 Defining Types

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

To define a type, select option 5 on the Environment Options panel, and press
Enter. Endevor displays the Type Request panel.
----------------------------OPTION
TYPE REQUEST
----------------------------------
===>
blank - Display
# - Delete type
C - Create type
U - Update type
type definition
definition
definition
definition
SYSTEM
===> ADMIN
TYPE
===> PROCESS
STAGE
===> T
T - TEST
Q - QA
3.7 Defining Types
3.7.2 Procedure: Types

1. In the fields on the Type Request panel, type the following, and press
Enter:
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 to
Step 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 Step
4.
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 the
following section.
For details on how to define binary files, see the appendix Working with
Binary Files.
3.7 Defining Types
3.7.3 Type Definition Panel

CREATE
----------------------- TYPE DEFINITION ------------------------------COMMAND ===>

CURRENT ENV:
NEXT ENV
:
SMPLTEST
SMPLTEST
STAGE ID:
STAGE ID:
T
Q
SYSTEM:
SYSTEM:
ADMIN
ADMIN
TYPE:
TYPE:
COBOL
COBOL
DESCRIPTION
UPDATED:
===> Cobol Source Code

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
--------------------- 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 Panel

The use of this panel varies by processing option.
With this option
Use this panel to
Display
Display a type definition.
Delete
View a type definition and verify that you want to

delete it. Press End to cancel a delete request.
Create
Define the new type.
Update
Modify a type definition.
Once you have entered the necessary information on the panel, press Enter to
perform the requested processing.
3.7 Defining Types
3.7.5 Type Definition Panel Fields

3.7.5.1 Identification Fields

The first four fields on the Type Definition panel display the current location
and type name. These fields are display-only fields.
Field
Description
Current Env
Stage ID
Name of the current stage.
System
Type
Name of the type.
The next four fields indicate the next location on the map, the type name at
that location, and last time the type definition was updated.
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 can

change the type name when you access this panel in
create or update mode.
Description
Displays a 1- to 50-character description of the type.
Updated

to update the type definition. When creating a new
type definition, this field is blank.
CAUTION:
Type names cannot be changed across the map.
3.7 Defining Types
3.7.5.2 Element Options

Field
Description
Fwd/Rev/Img Delta
Specifies delta storage format for elements of this

type. 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 base

form of elements stored in reverse delta format.
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. The

default is *NOPROC*. When you type or update the
name of the processor group, then press Enter,
Endevor displays a Processor Group Definition panel.
If the specified processor group exists, you can
use the Processor Group Definition panel to
verify or modify the processor group.
If the specified processor group does not exist,
you can use the Processor Group Definition panel
to create it as a new processor group. For more
information, see the Extended Processors Guide.
Regression Pct
Maximum acceptable regression percent for elements

of this type (2 digits). The use of a regression
percentage of 00 turns off regression testing for that
type no change or base regression messages are
issued.
Note: If the delta storage format for this type is I
(full-image delta format), the regression percent must
be 00.
Regr Sev
Determines severity of the error message issued when

Endevor detects regression. Acceptable values are:
Source Length
I Informational message.
W Warning message.
C Default. Critical message.
E Fatal message.
Logical record length in source statements. The

maximum allowable value is 32,000. For
variable-length records, this length does not include
the four-byte record header. For binary files, 32,000
is recommended.
3.7 Defining Types
Field
Description
Compare From
Position within each statement at which Endevor

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

stops comparing to identify changed statements (5
digits in the range 1-32,000). If you plan to use
in-stream data in processors, set this value to 80 for
type Process. Default is 72.
Auto Consol
Indicates whether Endevor is to consolidate change

levels automatically. Acceptable values are:
Y Consolidate automatically. When you create
the 96th change level for an element, Endevor
consolidates 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 the

type (1-8 characters).
Note: If you specify link-edit in this field, you
cannot use name or alias statements in the link step
of processors associated with this type.
3.7 Defining Types
Field
Description
PV/LB Lang
Required field used for internal purposes as well as

with AllFusion CA-Librarian or AllFusion
CA-Panvalet. The 1- to 8-character AllFusion
CA-Panvalet or AllFusion CA-Librarian source
language for the type.
Acceptable values for AllFusion CA-Panvalet:
ANSCOBOL
ALC
AUTOCODE
BAL
COBOL
COBOL-72
DATA
FORTRAN
JCL
PL/1
RPG
USER18
USER78
Acceptable values for AllFusion CA-Librarian:

ASM
COB
DAT
FOR
FRG
GIS
GOF
JCL
PLF
PL/1
RPG
TXT
VSB
Note: If you plan to use in-stream data in

processors, 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 which

Endevor consolidates change levels. Default is 96.
For example, if the value in this field is 70, Endevor
consolidates levels when change level 71 is reached.
3.7 Defining Types
Field
Description
HFS RECFM
Identifies the record delimiter used in a HFS file. A

record delimiter is necessary due to the nature of
HFS files. HFS files contain one large data stream;
therefore, a delimiter is used to identify individual
records within that data stream.
This is also true for elements associated with a type
defined as Data Format=Text when the element is
transferred between Endevor and AllFusion CM
Enterprise Workbench. AllFusion CM Enterprise
Workbench recognizes and appends the delimiter for
the exchanged records.
If a delimiter is not specified, the system defaults to
NL.
Acceptable delimiter values are:
COMP Variable length records compressed by
Endevor
CR Carriage return. ASCII and EBCDIC value
"CR". The hex value is '0D'.
CRLF EBCDIC Carriage return\line feed. The
hex 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 and
OBROWSE editor.
V Variable. The first two bytes of the record
contain the RDW (record descriptor word). The
RDW contains the length of the entire record,
including the RDW.
Note: For details on exchanging binary files between
Endevor and AllFusion CM Enterprise Workbench,
see the appendix Working with Binary Files.
3.7 Defining Types
Field
Description
Lvls to Consol
Indicates the number of deltas to consolidate when

the number of levels reaches the figure in the
CONSOL AT LVL field. Default is 50. This value
must be zero if AUTO CONSOL=N, and cannot be
greater than the value in the CONSOL AT LVL field.
When moving or transferring with history, Endevor
consolidates 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 the
value in the CONSOL AT LVL field is 70, at level 71
Endevor consolidates the oldest 30 deltas into a single
consolidation level (level 01).
Data Format
Indicates the element classification type and is used

for file conversion when transferring files between
Endevor and AllFusion CM Enterprise Workbench.
BBinary. An element exchanged between
AllFusion CM Enterprise Workbench and
Endevor is not modified. This applies in both
directions.
TText. Character set conversion is applied to an
element.
blankBlank. AllFusion CM Endevor
Workbench is not installed or this feature does
not apply to this type. If left blank, this value
defaults to binary when exchanging files between
Endevor and AllFusion CM Enterprise
Workbench.
For details on defining element types associated with
files exchanged between Endevor and AllFusion CM
Enterprise Workbench, see the AllFusion CM
Enterprise Workbench User Guide
3.7 Defining Types
Field
Description
File Ext
Indicates the 0- to 8-character file extension to be

used by the AllFusion CM Enterprise Workbench for
elements of this type. The extension can contain
mixed case characters of a-z, A-Z and 0-9, or all
blanks. Trailing blanks are supported; embedded
blanks are not supported.
For details on defining element types associated with
files exchanged between Endevor and AllFusion CM
Enterprise Workbench, see the AllFusion CM
Enterprise Workbench User Guide
3.7.5.3 Component List Options

The component list base and delta members are stored in the delta library
defined in the type definition.
Field
Description
Fwd/Rev Delta
Specifies delta storage format for component list

information. Acceptable values are:
R Reverse delta format.
F Default. Forward delta format.
Auto Consol
Indicates whether Endevor is to consolidate change

levels automatically. Acceptable values are:
Y Consolidate automatically. This is the
default 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 are
described in 3.7.9, Using Symbolics to Define Base and Delta Libraries on
page 3-43.
Field
Description
Base/Image Library
(Required)
Name of the base library for the type. Can be PDS,

AllFusion CA-Panvalet, AllFusion CA-Librarian, or
Endevor LIB.
3.7 Defining Types
Field
Description
Delta Library
(Required)
Name of the delta library for the type. Can be PDS,

AllFusion CA-Panvalet, AllFusion CA-Librarian, or
Endevor LIB.
Include Library
(Optional)
Name of the PDS, ELIB, AllFusion CA-Panvalet, or

AllFusion CA-Librarian INCLUDE library for the
type. If specified, members can be included and
expanded from this library.
Note: If an ELIB is specified as an INCLUDE library,
it must be reverse delta and have a name that is not
encrypted.
Source Library
(Optional)
Data set name of source output library.
Expand Includes
(Optional)
Indicates whether Include statements are expanded

when the element is written to the source output
library. Acceptable values are:
Y Expand Include statements.
N Do not expand Include statements.
3.7.6 Type Naming Conventions

Consider using generic type names, such as COBOL. You can then create as
many processor groups as you need to handle the variations within each type.
For instance, for type COBOL, you could create processor groups to tell
Endevor what type of COBOL must be processed. For more information on
processor groups, see the Extended Processors Guide.
3.7.7 Suggested Naming Standards

A list of suggested naming standards for types follows. This list is not
complete 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 Defining Types
3.7.8 Element Storage Formats

You can store elements in either reverse delta, forward delta, or full-image
delta format.
In reverse delta format, the element base is the current image of the
element. Endevor re-creates previous levels of the element by applying
delta levels to this base. Using reverse deltas allows you to store the
element base in standard PDS format (not encrypted, non-compressed).
In forward delta format, the element base is the source form of the element
when it is first added into Endevor. When Endevor processes elements
stored in this format, it applies all delta levels to the base to create the
current image of the element. If you select this format, Endevor encrypts
and compresses both the base and deltas.
In full-image delta format, sites can specify, by element type, that a
compare is not performed. Instead, Endevor makes each element level a
full image of the element.
Note: There is no appreciable performance difference between the delta
storage formats.
3.7.8.1 Reverse Delta Considerations

If you select the reverse delta unencrypted storage format, Endevor does not
allow 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 outside
utilities 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 still
be 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 LIB
data 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 in
encrypted/compressed format, which:
Provides DASD savings of 10-40%.
Allows one type to share a single base and single delta library across
stages 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 elements
from one location to another location. There are certain types of elements,
such as USS binary executables and machine-generated source, where this
source compare is impossible or unnecessary. In other cases, the Endevor
compare algorithm can require a significant amount of time to complete.
Note: Source changes between element levels are not available when
full-image delta is used. Only display or print requests for "BROWSE,"
"CHANGE SUMMARY," and "MASTER" requests are allowed for full-image
elements. Requests for "CHANGES" and "HISTORY" display are not
supported.
With the full-image implementation, Endevor provides the ability to:
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 Libraries

Endevor allows you to define base, delta, source output, and INCLUDE
libraries using symbolics. This allows the same type definition to point to
different libraries based on the inventory classification of the element.
Organize libraries by
Using this
symbolic
or this alias
Site
&C1SITE
Environment
&C1ENVMNT
&C1EN
Stage
&C1STAGE
&C1ST
Stage 1
&C1STAGE1
&C1ST1
3.7 Defining Types
Organize libraries by
Using this
symbolic
or this alias
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
Use these symbolics when specifying base and delta libraries on type definition
panels. Endevor then replaces the symbolic with the proper information from
the action request.
Example: The library specification:
&C1SYSTEM..&C1SUBSYS..&C1STGID..SRCLIB
would build a library called SRCLIB for each subsystem/stage combination
within a given system.
3.8 Defining the Type Processing Sequence

You have the option of enforcing an element type processing sequence within
an environment/system definition or through the definition of a single file
which enforces an element type processing sequence at the site level. With
Global Type Sequencing, all elements across all environments follow the same
processing sequence.
To define the relative sequence of processing for the various element types in
an environment/system, select option 7 from the Environment Options Menu.
A type processing sequence is used when multiple element types are processed
within a single batch request.
Before using this option, you must first define at least two element types for
the system (see 3.7, Defining Types on page 3-31, for more information).
Each time you add or delete a type thereafter, use option 7 again to redefine
the relative order of processing for the system. When a new type is added, it
defaults to being processed last.
To define Global Type Sequencing, see the chapter "Global Type
Sequencing."
3.8.1 Type Sequence Request Panel

When you select option 7 on the Environment Options panel and press Enter,
Endevor displays the Type Sequence Request panel.
-----------------------OPTION
TYPE SEQUENCE REQUEST
------------------------------
===>
blank - Display type processing sequence

U - Update type processing sequence
SYSTEM
===> ADMIN
STAGE
===> Q
T - TEST
Q - QA
3.8.2 Procedure: Type Processing Sequence

From the Type Sequence Request panel, follow this procedure to define the
type processing sequence:
1. Select an option (Blank or U).
4. Enter a stage ID.
5. Press Enter.
Enter, 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 the following
section.
3.8.3 Type Processing Sequence Panel

Use this panel to review the current processing sequence for types defined to
this stage and to redefine the sequence, if desired. To reorder a type, change
the appropriate Relative Processing 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
--------------COMMAND ===>
TYPE PROCESSING SEQUENCE
CURRENT ENV:
NEXT
ENV:
SMPLTEST
SMPLPROD
STAGE ID:
STAGE ID:
UPDATED:
23OCT2 17:9 BY CHARPER
Q
P
SYSTEM:
SYSTEM:
----------- Row 1 to 2 of 2
SCROLL ===> CSR
ADMIN
ADMIN
RELATIVE
PROCESSING
TYPE
DESCRIPTION
SEQUENCE
1
PROCESS
ENDEVOR PROCESSOR DEFINITIONS
2
COBOL
Cobol Source Code
Bottom of data
3.8.3.1 Type Processing Sequence Panel Fields

Panel fields are described below. All fields but Relative Processing Sequence
are display-only fields.
Field
Description
Current Env
Stage ID
ID of the current stage.
System
Next Env
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

to update the processing sequence definition. When
creating a new type processing sequence, this field is
blank.
Field
Description
Relative Processing
Sequence
A 3-digit number that defines the relative processing

order for processors executed in batch, for the type
displayed to the right. Type over this number as
appropriate to change the type processing.
Example
Assume you have these processors set up in this
sequence:
010
020
030
040
CLISTS
JCL
PROC
COPYBOOK
You decide that you want to run JCL after PROC.

You can reorder the processors by typing over the
appropriate sequence numbers; in this example, you
need renumber only JCL and PROC, as follows:
025 JCL
015 PROC
Note: Other sequence numbers do not need
adjusting. You can use any value from 1- 9 to
indicate a changing sequence; that is, instead of
assigning 025 to JCL, you could use 021 or 029. The
value you enter must be unique. If you enter a
duplicate number, you receive an error message.
When you press Enter, Endevor redisplays the panel
to reflect the new order, with the numbers adjusted
to start with 010 and increment by 10. In the
example shown above, the panel would reflect the
following sequence:
010 CLISTS
020 PROC
030 JCL
040 COPYBOOK
Type
Name of the type whose relative processing sequence

is shown to the left.
Description
Description of the type.

3.9.1 Type Data Set Request Panel
To view and optionally change the name of one or more data sets defined for
use within a particular system, select option 8 on the Environment Options
Menu. Data sets are associated with a system through the definition of the
element types within that system.
When you select option 8, and press Enter, Endevor displays the Type Data Set
Request panel.
-------------------------OPTION ===>
TYPE DATA SET REQUEST
----------------------------
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 Definitions

From the Type Data Set Request panel, follow this procedure to view or
change 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 Enter
and proceed to Step 6.
If Endevor displays a Type Data Set Definition panel, proceed to Step
6.
6. Type or change information as necessary on the Type Data Set Definition
panel, and press Enter to save the changes. For field descriptions, see the
following section.
3.9.3 Type Data Set Panel

Endevor displays this panel after you select a system. It lists the data sets
defined for the element types within that system, in order as they were
defined. To change a library, type over the data set name, and press Enter.
DISPLAY ---------------------COMMAND ===>

CURRENT ENV:
NEXT
ENV:
SMPLTEST
SMPLTEST
TYPE DATA SETS
STAGE ID:
STAGE ID:
Q
Q
SYSTEM:
SYSTEM:
-------------- Row 1 to 3 of 3
SCROLL ===> CSR
ADMIN
ADMIN
DATA SET NAME
--- LAST MODIFIED --USER

DATE
TIME TYPE
MSG
CA.ENDEVOR.SMPL&C1ST..BASE
JSMYTHE 19SEP2 11:28 ??
CA.ENDEVOR.SMPL&C1ST..DELTA
JSMYTHE 19SEP2 11:28 ??
CA.ENDEVOR.SMPL&C1ST..SRCLIB
CHARPER 22OCT2 17:17 ??
Bottom of data
3.9.3.1 Type Data Set Panel Fields

The following list describes the panel fields. All fields but Data Set Name are
display-only fields.
Field
Description
Current Env
(Current) Stage ID
ID of the current stage.
(Current) System
Next Env
(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 defined

within this system. For each element type, the list
includes the base library, delta library, Include
library, and source output library, as appropriate to
the type definition. The libraries are displayed in
order as they were defined to Endevor. Type over
this field to change one or more library names.
Last Modified by
The Last Modified By fields identify the user ID of

the last user to update the type data set as well as the
date 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 not
catalogued.
*ISYM An invalid Endevor symbol was
specified in the data set name.
*SERR A symbol parsing error occurred.
*IDSN A new data set name specified that
contains invalid characters.
*NMNT The volume on which the data set is
catalogued is not accessible (therefore the data set
organization cannot be derived).
*MVOL The data set is a multi-volume data
set.
*CTIO An I/O error occurred while trying to
locate the data set in the system catalog.
*ERR An unexpected error occurred.
*UPDT The data set update was processed and
completed.
3.10 Displaying Environment Information

3.10.1 Environment Information Panel
To display the environment definitions defined during installation, select
option E on the Environment Options Menu, and press Enter. Endevor
displays the Environment Information panel. The values displayed on this
panel 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...................
SMF Activity..............
SMF Security..............
MVS/DB Bridge.............
(NONE)
N
N
N
To return to the Environment Options Menu, press End.
3.10.1.1 Environment Information Panel Fields

The following list describes the panel fields. All fields except for CURRENT
ENVIRONMENT are display-only fields.
Field
Description
Current Environment
Name of the current environment. To display the

details for another environment, enter the
environment's name in this field, and press Enter.
Title
Descriptive title for the current environment.
Next Environment
User Security Table
Name of the User Security Table currently in use. 1
Resource Security
Table
Name of the Resource Security Table currently in use.

1
Journal
Applicable only to users of Endevor's Point in Time

Recovery facility. Name of the journal file used by
this facility.
SMF Activity
Indicates whether the SMF facility is active for this

environment: Y or N 2
Field
Description
SMF Security
Indicates whether SMF security has been turned on

for this environment: Y or N 2
MVS/DB Bridge
Indicates whether the Endevor to CA-Endevor/DB

Bridge 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 cycles
at your site, then organize these stages into environments. This section of this
manual illustrates this process.
Applications in each life cycle follow a unique route through the
environment/stage locations that you have defined. You can set up as many
routes as you need to accommodate different life cycles at your site. These
routes make up the map for your site.
Endevor uses these routes to automatically add, display, retrieve, move, and
generate inventory in a given life cycle.
Consider the following examples:
Use environments DEV, QA, and PROD for production applications (Route
1), with an environment, QFIX, to handle emergency fixes to the
applications (Route 2). Routes 1 and 2 might look like this:
Chapter 4. Mapping 4-1
Use environments TSTDEMO and DEMO for the software used to

demonstrate the production applications (Route 3). Route 3 might look
like this:
Note: When defining a map, the exit stage for an environment must always
be Stage 2. The entry point into the next environment can be Stage 1 or Stage
2.
4.1.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 to
identify inventory classifications at the successive locations in each route.
4.1.2 Establishing Routes in the Defaults Table

To define a route, add the following line to one or more C1DEFLTS
TYPE=ENVRNMNT sections of the Defaults Table:
NEXTENV=(environment-name, stage-id)
Variable
Description.
environment-name
The name of the next environment on the route.
stage-id
The one-character identifier of the first stage in that

environment that is on the route. The stage ID is
optional, and if included, must be defined in the
Defaults Table.
Example: To define Route 1 in the preceding section, add the following to

the C1DEFLTS TYPE=ENVRNMNT section:
NEXTENV=QA
For environment DEV.
NEXTENV=(PROD,P)
For environment QA.
Note: If you do not provide a stage ID, the specification defaults to Stage 1 of
the next environment.
4.1.3 Mapping Inventory Classifications

You relate system, subsystem, and processor group names between stages in a
route using the NEXT SYSTEM, NEXT SUBSYSTEM, and NEXT GROUP fields
on the respective definition panels. You can change:
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 processor
group names consistent across stages and environments.
Note: If you plan to change system or subsystem names across your map and
use package component validation, see the Packages Guide for information
about the potential impact of these name changes on package component
validation functions.
To continue the Route 1 example, assume that there are the following
inventory 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 table below indicates the values the administrator would enter in the
NEXT SYSTEM, NEXT SUBSYSTEM, and NEXT GROUP fields.
DEV
UNIT
DEV
INT
QA
QA
QA
HOLD
PROD PROD
FIX
PROD
NEXT
SYSTEM
FINANCE FINANCE FINANCE FINANCE NONE NONE
NEXT
SUBSYSTEM
PO
NEXT
GROUP
BTCHCOB BTCHCOB BTCHCOB BTCHCOB N/A
PO
PO
PO
NONE NONE
NONE
Note: Stage 1, Fix, of environment PROD, is not one of the locations on

this map route, making a next group specification "not applicable".
For procedures and descriptions of these panels, see Chapter 3, Defining
Inventory Structures (system and subsystem definitions) and the Extended
Processors Guide (processor group definition).
4.2 Design Strategies and Guidelines

4.2.1 Routes
The routes that you develop for your site can have a significant impact on
your success in using Endevor. When defining routes, keep in mind that:
System and subsystem names can change only when going from one
environment to another.
Processor group names can change when going between stages or between
environments.
The examples that follow present two strategies for defining routes. Use these
examples as a starting point when developing your own maps.
4.2.2 Stand-alone Routes

You can have more than one route in your map. For example, you might
create one route for the production software life cycle, and a second route for
the life cycle of the demonstration system for this production software.
Each route is defined separately:

Route 1 includes environments DEV, QA, and PROD.
Route 2 includes environments TSTDEMO and DEMO.
4.2.3 Converging Routes

Different routes can converge to include the same stages. For example, a site
may have different environments for developing financial, manufacturing, and
administrative applications, but have only one QA and one production
environment. 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 Route

This example suggests a way to take advantage of map routes while
minimizing the number of environments defined in the Defaults Table.
Consider an organization where Bill and Mary are developing a purchase
order application. Quality assurance work on the completed PO application
takes place in environment QA, and the production application is maintained
in environment PROD.
To keep a single development environment (DEV), the administrator creates
system BILL and system MARY in environment DEV, then defines subsystem
PO to each of these systems. All four developers are working on COBOL
programs, which have processor group COBOL in all stages of the route.
The administrator defines an environment map by adding the lines:
NEXTENV=QA
To the C1DEFLTS TYPE=ENVRNMNT

section for environment DEV.
NEXTENV=(PROD,P)
To the C1DEFLTS TYPE=ENVRNMNT

section for environment QA.
The administrator fills in the NEXT SYSTEM, NEXT SUBSYTEM, and NEXT
GROUP fields on the respective definition panels as follows:
DEV UNIT
DEV INT
QA QA
PROD
FIX
PROD
PROD
NEXT
SYSTEM
FINANCE
(on system BILL
and system MARY
definition panels)
FINANCE
(on system BILL
and system MARY
definition panels)
FINANCE FINANCE NONE
NONE
NEXT
SUBSYSTEM
PO
PO
PO
NONE
NEXT
GROUP
BTCHCOB
BTCHCOB
BTCHCOB BTCHCOB N/A
QA
HOLD
PO
NONE
NONE
This route looks like this:
4.2.5 Implementation Checklist

When defining routes:
1. Set up routes that reflect your software life cycles. Draw a diagram of the
routes 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 to
identify inventory classifications and processor groups at the successive
locations in each route.
Note: You can also define your maps using batch SCL commands. For
details, see the SCL Reference Guide.
4. Run CONRPT07, System Definition Profile, to verify the routes are set
correctly. Also, run CONRPT07 whenever you change a route to verify
that you have made the modifications correctly.
For a sample of the CONRPT07, see the Reports Guide.
Chapter 5. Element Registration
Chapter 5. Element Registration 5-1
5.1 Overview
5.1 Overview
The element registration feature enables you to choose whether you want to
restrict the use of the same element name across subsystems within a given
system, or element types. Duplicate element names can be problematic;
however, there are situations where they are desirable - for example, the same
element name is used for a program as well as its JCL.
Endevor provides two options that enable you to allow or disallow duplicate
element names. One option enables you to control the use of duplicate
element names at the system and subsystem level. The other option enables
you to control the use of duplicate element names at the processor group level.
Note: Verify you are using the same message severity level for the system in
each environment where the system appears. If you do not, element actions
may behave in an unpredictable manner. Similarly, if element registration is
activated for a system, make sure it is activated in each environment in which
it appears.
5.2 Controlling Duplicate Element Names at the System and Subsystem Level
5.2 Controlling Duplicate Element Names at the System

and Subsystem Level
The Element Registration option enables you to control whether duplicate
element names are allowed across subsystems within a system. During action
processing, when the subsystem associated with the element is validated,
Endevor checks the option to see if duplicate element names are allowed. The
System Definition parameters Duplicate Element Name Check and Msg
Severity Lvl, govern this option. You can specify the following parameter
values:
Value
Description
E (Error)
The same element name exists within another subsystem

under the same system; the action is terminated and an error
message is issued.
C (Caution)

under the same system; the action is performed and a caution
message is issued.
W
(Warning)

under the same system; the action is performed and a warning
message is issued.
5.2 Controlling Duplicate Element Names at the System and Subsystem Level
The System Definition panel displays the parameter values in the Duplicate
Element Name Check and Msg Severity Lvl fields highlighted in the following
screen.
UPDATE

NEXT
ENV:
SMPLPROD
SYSTEM:
FINANCE
NEXT SYSTEM ===> FINANCE
SYSTEM TITLE ===> FINANCIAL APPLICATIONS
UPDATED:
GENERAL OPTIONS:
(W/C/E)
(W/C/E)
ACTIVATE OPTION
===> Y (Y/N)
VALIDATE DATA SET
===> N (Y/N)
LIBRARIES:
5.3 Controlling Duplicate Element Names at the Processor

Group Level
The processor group-level option enables you to control whether duplicate
element names and output types can exist within the same system but
different types. Through the use of a new field, described later in this section,
you have the ability to define the type of output produced by a processor
group. During action processing, if the element already exists at the target
location within the same system under a different type with the same output
type, the action is terminated or a warning message issued. To activate this
option, you must set the appropriate System Definition parameter value and
define the output type for the processor group. Both tasks are described next.
The System Definition fields, Duplicate Proc O/P Type Check and Msg
Severity Lvl, activate this option. You can specify the following parameter
values:
Value
Description
E (Error)
The same element name and same output type exist within
the same system and different type; the action is terminated
and an error message is issued.
C (Caution)
The same element name and same output type exist within
the same system and different type; the action is performed
and a caution message is issued.
W
(Warning)
The same element name exists within another system or

subsystem; the action is performed and a warning message is
issued.
The System Definition panel displays the parameter values in the Duplicate
Proc O/P Type Check and the Msg Severity Lvl fields highlighted in the
following screen.
UPDATE

NEXT
ENV:
SMPLPROD
SYSTEM:
FINANCE
UPDATED:
GENERAL OPTIONS:
(W/C/E)
(W/C/E)
ACTIVATE OPTION
===> Y (Y/N)
VALIDATE DATA SET
===> N (Y/N)
LIBRARIES:
5.3.1 Defining the Output Type

After enabling the processor group option, you need to define the output type.
The default output type is a concatenation of the element type and processor
group names. Using the default value ensures there are no registration
conflicts. Alternatively, you can define the output type using the Processor
Group Definition Panel. The output type field, PROCESSOR O/P TYPE, is
16-characters long. In the following example, we use LOADMODULE as the
output type for the generate processor. The output type is copied to the
element catalog record segment when the element is added or updated.
CREATE
----------------- PROCESSOR GROUP DEFINITION -------------------------COMMAND ===>

CURRENT ENV:
NEXT
ENV:
SMPLTEST
SMPLPROD
STAGE ID:
STAGE ID:
Q
P
SYSTEM:
SYSTEM:
ADMIN
ADMIN
TYPE:
TYPE:
COBOL
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
U - Update Symbolics
GENERATE PROCESSOR ===> GCIINBL
DELETE PROCESSOR
===> DLODNNL
MOVE PROCESSOR
===> MLODNNL
L - List Processor
FOREGROUND
===> Y
===> Y
===> Y
EXECUTION
(Y/N)
(Y/N)
(Y/N)
You can implement the processor group option for selected inventory. For the
inventory that should not be checked, leave the output value as it is originally
set; 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 Processors
Guide.
Chapter 6. Optional Features

This chapter describes how to install some of the optional features provided
with the Endevor.
If you are new to using Endevor you should become familiar with Endevor
basics before activating the optional features.
Chapter 6. Optional Features 6-1
6.1 Endevor Optional Feature Table ENCOPTBL

The optional feature table (OFT) supplied with Endevor provides you with a
simple, easy-to-use mechanism to customize the product for use at your site.
This facility enables you to configure your implementation of Endevor by
specifying which features you want to activate. After modifying the OFT
source, you must assemble and link the table, placing the output into the
Endevor execution library.
The optional feature table embedded in ENCOPTNS provides a description of
each option along with detailed information on parameter values and
downstream effects.
The OFT source, as distributed, contains each option already coded, but
inactive. To activate an entry, remove the asterisk (*) in column 1 and verify
that the second parameter, if required, contains the appropriate value.
Assemble and link-edit the table using member BC1JOPTF, located in
Endevor's JCLLIB.
6.1.1 Optional Feature Table Source

The table shown below is the sample optional feature table provided with the
Endevor installation files as member ENCOPTBL in the installation SOURCE
library:
ENCOPTBL TITLE 'ENDEVOR OPTIONAL FEATURES TABLE'

(C) 1987,25 COMPUTER ASSOCIATES INTERNATIONAL, INC.

NAME:
ENCOPTBL

DESCRIPTION: ENDEVOR OPTIONAL FEATURES TABLE.

FUNCTION:
THIS MEMBER CONTAINS THE SOURCE FOR THE OPTIONAL

FEATURES TABLE.

INSTRUCTIONS:

1. TAILOR THIS TABLE AS NEEDED.

THE OPTIONAL PTFS INCLUDED IN THIS TABLE ARE

DELIVERED IN A DE-ACTIVATED MODE. TO ACTIVE AN

ENTRY, REMOVE THE '' FROM COLUMN 1 OF THE

APPROPRIATE ENHOPT ENTRY OR ENTRIES.

2. ASSEMBLE AND LINKEDIT THE TABLE USING THE MEMBER

BC1JOPTF CONTAINED IN THE EXAMPLE JCLLIB LIBRARY.

ASSEMBLY RETURN CODES:

- NORMAL

4 - WARNING: FUNCTION COMPLETE WITH ERRORS.

12 - PARAMETER ERROR, TABLE SHOULD NOT BE LINKED.

16 - INTERNAL ERROR - TABLE SHOULD NOT BE LINKED.

CONTACT ENDEVOR SUPPORT.

INITIALIZATION KEYWORD. MUST BE FIRST ENTRY.

---------------------------------------------------------------------
ENCOPTBL ENHOPT INIT

THIS OPTION WILL CAUSE AN ISPF CONFIRMATION PANEL TO BE DISPLAYED
WHEN THE THE ELEMENT NAME IS OMITTED AND "Y" IS SPECIFIED FOR THE
SEARCH MAP LIST OPTION. SIGNIFICANT DELAYS MAY OCCUR BUILDING AN
ELEMENT SELECTION LIST FOR ALL ELEMENTS ACROSS MULTIPLE ENVIRONMENTS.
---------------------------------------------------------------------

ENHOPT ELMNM_PROMPT=ON

THIS OPTION WILL CAUSE AN ISPF CONFIRMATION PANEL TO BE DISPLAYED
WHEN THE PACKAGE ID IS OMITTED FROM THE PACKAGE PANEL. OMISSION OF
THE PACKAGE ID CAN CAUSE SIGNIFICANT DELAYS IN THE CONSTRUCTION OF
THE PACKAGE SELECTION LIST.
---------------------------------------------------------------------

ENHOPT PKGID_PROMPT=ON

THIS OPTION WILL ONLY PRINT 1 BANNER PAGE DURING THE CONLIST STEP.
CONLIST STEP. SPECIFY (ON,XX) WHERE XX IS THE NUMBER OF PAGES TO BE
PRINTED.
O317
---------------------------------------------------------------------

ENHOPT BANNER_PAGES=(ON,1)

BY DEFAULT, ENDEVOR ALLOCATES DATASETS WITHIN A CONCATENATION, USING
THE LARGEST BLOCKSIZE ASSOCIATED WITH ANY OF THESE DATASETS. MVS 4.3
MAY ISSUE AN ALLOCATION ERROR. THIS PTF CAUSES ENDEVOR TO ALLOCATE
EACH DATASET ACCORDING TO IT'S ACTUAL BLOCK SIZE.
O714
---------------------------------------------------------------------

ENHOPT BLKSIZE_CONCAT=ON

APPLIES TO LIST, DISPLAY AND QUICK EDIT. 'WHERE CCID =' SHOULD
ONLY SELECT BASED ON LAST ACTION CCID. LASTLEVEL CCID WILL STILL BE
USED FOR PRE R3. ELEMENTS.
O559,O574
---------------------------------------------------------------------

ENHOPT CCID_LST_LAST_ACT=ON

BATCH ONLY. CHANGE DEFAULT WHERE CCID = CURRENT CLAUSE TO
WHERE CCID = ALL
O322
---------------------------------------------------------------------

ENHOPT CCID_WHERE_ALL=ON

THIS OPTION BYPASSES FULL FOOTPRINT VERIFICATION AND ISSUES MESSAGE
C1G118I IF AN ERROR IS FOUND.
O57
---------------------------------------------------------------------

ENHOPT DELETE_NO_FP_CHK=ON

CAUSES THE USERID.C1TEMPR1.SSSS.MSGS AND USERID.C1#1TMPL.SSSS.LIST
DATASETS TO BE GENERATED WITHOUT A TSO SYSTEM ID QUALIFIER. WITH THIS
PTF ENABLED THE DATASET NAMES CREATED ARE USERID.C1TEMPR1.MSGS AND
USERID.C1TEMPR1.LIST, LIKE THEY WERE IN PRE-3.8 RELEASES.
O745
---------------------------------------------------------------------

ENHOPT DS_C1TEMPR1_SUFFX=ON

CHANGE THE NAMING CONVENTION ENDEVOR USES WHEN CREATING TEMPORARY
INTERNAL DATASETS FROM .RA. TO .RA.
CAUTION: SOME SYSTEMS DO NOT ALLOW APPLICATION PROGRAMS SUCH AS
ENDEVOR TO USE THIS CONVENTION.
O67

ALL TEMPORARY DATASETS WILL GET A 3RD QUALIFIER OF .RA. UNLESS
THIS OPTION IS SET AND (!) IF THE FILE IN QUESTION IS USED ANYWHERE
IN THE PROCESSOR WITH DISP=MOD AND (!) NO MODHLI HAS BEEN DEFINED IN
C1DEFLTS.
FOR FILES THAT ARE USED WITH DISP=MOD AND IF NO MODHLI HAS BEEN
DEFINED, ENDEVOR WILL GENERATE BY DEFAULT (OPTION COMMENTED) A DSN

WITH THE .RA. QUALIFIER.
IF THE OPTION IS SET (UNCOMMENTED) THEN THE RA QUALIFIER WILL BE

CHANGED FROM .RA. TO .RA. (ONLY FOR THIS SPECIFIC CASE).
---------------------------------------------------------------------

ENHOPT DS_INTERNAL_TEMP=ON

THE ENDEVOR PRIMARY OPTION AND FOREGROUND OPTION PANELS ARE
ARE TAILORED ACCORDING TO A USER'S AUTHORITY TO PERFORM AN ACTION OR
FUNCTION. NORMALLY, WHEN OPTIONS ARE OMITTED THE SUBSEQUENT OPTIONS
ARE RENUMBERED TO MAINTAIN A CONTINOUS SEQUENCE.

WITH THIS OPTION TURNED ON, IF A USER IS NOT AUTHORIZED FOR A PANEL
OPTION, THE OPTION NUMBER (LETTER) WILL SIMPLY BE BLANKED OUT TO
INDICATE THE OPTION IS UNAVAILABLE.

ENDEVOR FOR MVS WORKBENCH
O899
---------------------------------------------------------------------

ENHOPT FIXED_PANEL_OPT#S=ON

BY DEFAULT, WHEN SCL IS GENERATED BY BATCH BUILD OR PACKAGE BUILD
SCL, THE CONSTRUCTED SCL WILL ONLY CONTAIN THE WHERE CCID OR WHERE
PROCESSOR GROUP CLAUSE IF THE DISPLAY LIST SETTING IS SET TO NO.

IF THIS IS SET TO A VALUE OF (ON,1), THEN THE CONSTRUCTED SCL WILL
ALWAYS CONTAIN THE WHERE CLAUSE(S).
IF THIS IS SET TO A VALUE OF (ON,2), THEN THE CONSTRUCTED SCL WILL
NEVER CONTAIN THE WHERE CLAUSE(S).
O568
---------------------------------------------------------------------

ENHOPT GEN_WHERE_SCL=(ON,1)

ENHOPT GEN_WHERE_SCL=(ON,2)

IGNORE CASE SENSITIVITY WHEN PERFORMING LIST WHERE TEXT PROCESSING
IGNORE CASE SENSITIVITY WHEN PERFORMING LIST WHERE CCID PROCESSING

IGNORE CASE SENSITIVITY WHEN PERFORMING CCID VALIDATION
---------------------------------------------------------------------

ENHOPT MONOCASE_SEARCH=ON

IF THE DATASET NAME IN A PROCESSOR IS CODED USING THE DSN=IGNORE
PARAMETER, THE DD STATEMENT IS NOT ALLOCATED. THIS INCLUDES DD'S
THAT ARE IN THE CONCATENATION.
O524
---------------------------------------------------------------------

ENHOPT IGNORE_SKIP_ALLOC=ON

SUPPORT LIBRARIAN INCLUDE ("-INC") IN COLUMNS 1-8 FOR ELIBS.
O482,O961
---------------------------------------------------------------------

ENHOPT INCLUDE_COB=ON

THIS PTF CAPTURES ADDITIONAL MESSAGES PRODUCED BY THE INFOMAN API.
MESSAGES ARE WRITTEN TO THE APIPRINT DATASET. PRIOR TO INVOKING
ENDEVOR, THE APIPRINT DATASET MUST BE ALLOCATED.
O228
---------------------------------------------------------------------

ENHOPT INFO_API_MSGS=ON

THE ENDEVOR/INFOMAN INTERFACE CONVERTS ALL DATES (PACKAGE, ELEMENT
AND CURRENT DATE) FROM THE DEFAULT FORMAT OF MM/DD/YY TO DDMMMYY.
O61
---------------------------------------------------------------------

ENHOPT INFO_DATE_FORMAT=ON

CURRENTLY, THE PACKAGE CAST AND RESET FUNCTIONS WILL DELETE THE
INFOMAN ACTIVITY RECORDS ASSOCIATED TO THE PACKAGE BEING CAST
OR DELETED. WHEN INFOMAN ACTIVITY RECORDS ARE KEPT AS A
HISTORY OF THE PARTICULAR PACKAGE, DELETING THESE ACTIVITY
RECORDS WOULD REMOVE THAT HISTORY. THIS OPTIONAL PTF WILL
BYPASS THE DELETE OF THESE INFOMAN ACTIVITY RECORDS, AND IT IS
THE ONUS OF THE USER TO REMOVE THEM FROM THE INFOMAN DATABASE.
O857

ENHOPT INFO_PKG_ACTY=ON

ALLOW LIBRARIAN CONTROL CHARACTERS (/, ++ AND --) IN COLUMNS 1 & 2
OF THE SOURCE STATEMENTS.
O622
---------------------------------------------------------------------

ENHOPT LB_CNTL_CHAR=ON

DETERMINE IF LIBRARIAN SEQUENCE NUMBERS ARE WITHIN THE RANGE
SPECIFIED ON THE TYPE DEFINITION. IF SO, GENERATE THE SEQCHK KEYWORD
ON THE -ADD AND -SEL CONTROL CARDS.
O19
---------------------------------------------------------------------

ENHOPT LB_SEQNUM=ON

CHANGE THE LIBRARIAN CONTROL CARDS TO SUPPRESS WRITTING OF
LIBRARIAN AUDIT INFORMATION. THIS MAY BE NECESSARY FOR SOURCE
MEMBERS GREATER THAN 1, LINES.
O618
---------------------------------------------------------------------

ENHOPT LB_SUPPRESS_AUDIT=ON

CAUSES THE ALTERNATE ID TO NOT BE USED WHEN EXITS ARE INVOKED.
O573
---------------------------------------------------------------------

ENHOPT NO_ALTID_EXIT=ON

THIS OPTION TURNS OFF EXCP PROCESSING FOR OLD XA SYSTEMS OR FOR
DEBUGGING PURPOSES.
O28
---------------------------------------------------------------------

ENHOPT NO_EXCP=ON

THIS OPTION CAUSES THE LOAD-MODULE FOOTPRINT NOT TO BE READ.
O62
---------------------------------------------------------------------

ENHOPT NO_LMOD_FP=ON

BYPASS THE JCL DISPLAY OF THE PROCESSOR EXECUTED DURING ACTIONS
AND/OR BYPASS PRINTING C1G7I AND/OR C1G9I MESSAGES
EXPLANATION :
IF YOU WANT TO SUPPRESS THE PROCESSOR LISTING USE (ON,1) O324
IF YOU WANT TO SUPPRESS MSGS C1G7I USE
(ON,2) O1746
IF YOU WANT TO SUPPRESS MSGS C1G9I USE
(ON,4) O1746
IF YOU WANT TO SUPPRESS A COMBINATION OF MSGS USE (ON,N), WHERE N

EQUALS THE SUM OF THE PREVIOUSLY PROPOSED VALUES.

EG : USE (ON,7) TO SUPPRESS ALL THESE MESSAGES.

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

ENHOPT NO_PROC_PRINT=(ON,1)

INCREASES THE SIZE OF THE PARSER HEAP. THE DEFAULT VALUE IS 32,
BYTES. SPECIFY (ON,XX), WHERE XX IS THE NUMBER OF 4,96 (4K) BYTE
PAGES TO BE ALLOCATED. FOR EXAMPLE, (ON,1) CAUSES 1 4K PAGES TO
BE ALLOCATED, INCREASING THE STACK SIZE TO 4,96 BYTES.
O531
---------------------------------------------------------------------

ENHOPT PARSER_HEAP_SIZE=(ON,1)

WHEN EXECUTING A MOVE ACTION AND THE PROCESSOR GROUP IS NOPROC,
THE MOVE PROCESSOR IS EXECUTED, BUT MESSAGE FPVL3E IS ISSUED
ISSUED DURING COMPONENT VALIDATION IF THE SOURCE OUTPUT LIBRARY
IS USED AS A COPYBOOK LIBRARY. THIS PTF CHANGES THE DEFAULT
PROCESSOR TO THE GENERATE PROCESSOR INSTEAD OF THE MOVE PROCESSOR
IN THIS SITUATION.
O687
---------------------------------------------------------------------

ENHOPT PROC_MOVE_DFLT=ON

ALLOW PANVALET CONTROL CHARACTERS (/, ++ AND --) IN COLUMNS 1 & 2
OF THE SOURCE STATEMENTS.
O551
---------------------------------------------------------------------

ENHOPT PV_CNTL_CHAR=ON

THE TRANSLATE TABLES USED IN NON-ENGLISH VERSIONS OF THE ISPF FIND
COMMAND CHARACTER '!' (X'5A) USED IN THE PROGRAM CONSTANT "!ENDIE4M"
TO BE INVALID. THIS OPTION CHANGES THE CHARACTER TO "|" (X'4F').
THE OPTION MAY BE MODIFIED FOR (X'4F'). THE PTF MAY BE MODIFIED TO
FIT THE LANGUAGE BEING USED.
O823
---------------------------------------------------------------------

ENHOPT QE_CMDCHAR=(ON,|)

ALLOW EDITING OF DOUBLE-BYTE CHARACTER SET DATA SETS.
O58
---------------------------------------------------------------------

ENHOPT QE_MIXED=ON

THIS OPTION CAUSES SOME AMOUNT OF STORAGE TO BE RESERVED FOR MVS.
THE PARAMETER SPECIFIES THE NUMBER OF 1K PAGES TO BE RESERVED.
SPECIFY (ON,XX) WHERE XX IS THE NUMBER OF PAGES TO BE RESERVED.
EXAMPLE, RESERVE_OPSYS_STG=(ON,1) RESERVES 1K FOR THE OPERATING
SYSTEM.
O231
---------------------------------------------------------------------

ENHOPT RESERVE_OPSYS_STG=(ON,1)

BYPASS THE SECURITY CHECKS FOR THE LIST OR PRINT OF A LISTING MEMBER.
O958
---------------------------------------------------------------------

ENHOPT SEC_BYP_LST_PRT=ON

IF IN-HOUSE SECURITY IS DESIGNED TO EXPECT THE MOVE ACTION TO ISSUE
A SECURITY CALL AT THE TARGET LOCATION, THEN DO SECURITY CHECK AT
THE TARGET LOCATION DURING THE MOVE PROCESSING.
O517
---------------------------------------------------------------------

ENHOPT SEC_MOVE_TARGET=ON

CHANGE THE ALLOCATION DISPOSITION OF PACKAGE SHIP DESTINATION
DATASETS DEFINED IN THE IEBCOPY JOBS FROM DISP=OLD TO DISP=SHR.
O58
---------------------------------------------------------------------

ENHOPT SHP_DISP_SHR=ON

SPECIFY SHP_EXEC_FAIL=ON TO PREVENT THE SHIPMENT OF PACKAGES THAT
HAVE A PACKAGE STATUS OF "EXEC FAILED."
---------------------------------------------------------------------

ENHOPT SHP_EXEC_FAIL=ON

REMOVE THE VERSION/LEVEL SCL SYNTAX GENERATION FROM THE BUILD OF
TRANSFER SCL. THIS APPLIES TO BATCH AND PACKAGE PROCESSING.
O882
---------------------------------------------------------------------

ENHOPT TRANSFER_NO_VVLL=ON

ALLOW C1DEFLTS AND/OR C1UEXITS TO BE LOADED FROM AN UNAUTHORIZED
LOAD LIBRARY. BY DEFAULT, THESE TABLES MUST BE LOADED FROM AN
AUTHORIZED LOAD LIBRARY. TO ALLOW C1DEFLTS TO BE LOADED FROM AN
UNAUTHORIZED LOAD LIBRARY, THE FIRST BYTE CHANGED MUST BE SET TO
THE CHARACTER "N". TO ALLOW C1UEXITS TO BE LOADED FROM AN
UNAUTHORIZED LOAD LIBRARY, THE SECOND BYTE MUST BE SET TO THE
CHARACTER 'N'. ANY VALUE OTHER THAN 'N' FOR EITHER BYTE WILL CAUSE
AUTHORIZATION CHECKING TO BE PERFORMED.

NOTE THAT IF YOU ALLOW C1DEFLTS TO BE LOADED FROM AN UNAUTHORIZED
LIBRARY, THIS WILL ALLOW ALL TABLES LOADED VIA ENUXSITE TO BE
LOADED FROM AN UNAUTHORIZED TABLE AS WELL.
O486,O525
---------------------------------------------------------------------

ENHOPT UNAUTH_DFLTS_EXITS=(ON,NN) BOTH CAN BE UNAUTHORIZED

ENHOPT UNAUTH_DFLTS_EXITS=(ON,NY) C1DEFLTS CAN BE UNAUTHORIZED

ENHOPT UNAUTH_DFLTS_EXITS=(ON,YN) C1UEXITS CAN BE UNAUTHORIZED

ENHOPT UNAUTH_DFLTS_EXITS=(ON,YY) BOTH MUST BE AUTHORIZED

ALLOW ENDICNFG TABLE TO BE LOADED FROM CONLIB ONLY
O2718
---------------------------------------------------------------------

ENHOPT ENDICNFG_CONLIB=ON

USE CONCOMP1 COMPRESSION FOR FILES WITH RECORD LENGTHS LESS THAN
256.
O56
---------------------------------------------------------------------

ENHOPT USE_CONCOMP1=ON

INTERPRET DSORG=PS,LRECL=BLKSIZE AS A PANVALET OR LIBRARIAN LIBRARY.
NORMALLY, DATA SETS WITH DSORG=PS, LRECL=BLKSIZE IS TREATED AS A
NORMAL SEQUENTIAL FILE. HOWEVER, IT IS POSSIBLE TO DEFINE PANAVLET
LIBRARIES WITH THIS COMBINATION OF DCB ATTRIBUTES. APPLY THIS
OPTION TO FORCE ENDEVOR TO INTERPRET THIS KIND OF DATA SET AS A
PANVALET LIBRARY.
O498
---------------------------------------------------------------------

ENHOPT VALIDATE_PVLB=(ON,YN) ON FOR PV, OFF FOR LB

ENHOPT VALIDATE_PVLB=(ON,NY) OFF FOR PV, ON FOR LB

ENHOPT VALIDATE_PVLB=(ON,YY) ON FOR PV, ON FOR LB

WHEN VERIFY=FOOTPRNT IS CODED IN A PROCESSOR, AND THE VERIFICATION
FAILS, THE PROCESSOR STEP IS NOT EXECUTED, THE ELEMENT IS MARKED AS
"FAILED PROCESSOR EXECUTION" AND PROCESSOR EXECUTION IS TERMINATED.

ENABLING THE VFY_FP_FAILURES OPTION WILL CAUSE ENDEVOR TO TREAT
THE FOOTPRINT VERIFICATION FAILURE RETURN CODE AS THE STEP RETURN
CODE RATHER THAN THE ENDEVOR RETURN CODE. THIS WILL ALLOW EXE CUTION OF THE PROCESSOR TO CONTINUE AND ALLOW MAXRC, COND AND IF
CLAUSES TO TEST FOR FOOTPRINT VERIFICATION FAILURE.
O789
---------------------------------------------------------------------

ENHOPT VFY_FP_FAILURES=ON

THE "PKG_ELEMENT_LOCK" OPTION DIRECTS ENDEVOR TO LOCK ELEMENTS
REFERENCED BY A PACKAGE WHEN THE PACKAGE IS CAST. IF AN ELEMENT IS
ALREADY RESERVED FOR ANOTHER PACKAGE, THE CAST WILL FAIL (UNLESS THE
PACKAGE IS AN EMERGENCY-TYPE PACKAGE. ACTIONS WHICH ATTEMPT TO
MODIFY A RESERVED ELEMENT WILL BE FAILED BEFORE THE ACTION BEGINS.

VALID SPECIFICATIONS FOR THIS OPTION ARE (ON,Y), (ON,N) OR OFF.
THE FIRST VALUE INDICATES WHETHER THE ELEMENT LOCK FEATURE IS ACTIVE.
THE SECOND VALUE DIRECTS THE PACKAGE LOCK FACILITY TO LOCK THE
ENDEVOR TARGET LOCATION OF AN ACTION (ADD, GENERATE W/COPYBACK, MOVE,
RESTORE, TRANSFER, AND UPDATE). LOCKING THE TARGET LOCATION WILL
PROVIDE ADDITIONAL ASSURANCE THAT THE SUBSEQUENT EXECUTION OF THE
PACKAGE WILL NOT FAIL DUE TO INTERFERENCE FROM OTHER PACKAGES
OR ACTIONS EXECUTED FROM OUTSIDE OF A PACKAGE.
---------------------------------------------------------------------

ENHOPT PKG_ELEMENT_LOCK=(ON,Y) PKG ELM LOCK ACTIVE - SRC & TGT

ENHOPT PKG_ELEMENT_LOCK=(ON,N) PKG ELM LOCK ACTIVE - SRC ONLY

ENHOPT PKG_ELEMENT_LOCK=OFF
PKG ELM LOCK INACTIVE

O2766 UNLOCK_FAILED_ACTION.
NORMALLY WHEN AN ELEMENT IS LOCKED BY A PACKAGE, ONLY THE SUCCESFULL
COMPLETION OF THE ACTION WILL RELEASE THE LOCK ON THE ELEMENT.
WITH THIS OPTION SET, THE LOCK WILL BE RELEASED WHEN THE PACKAGE
ACTION COMPLETES, SUCCESSFUL OR NOT.

IMPORTANT :
THIS OPTION, WHEN SET, CAN CAUSE PACKAGE RESTARTS TO FAIL :
IF A PACKAGE ACTION FAILS AND THE ELEMENT IS UNLOCKED THE PACKAGE
CAN ONLY BE RESTARTED SUCCESSFULLY IF THE FAILED AND UNLOCKED
ELEMENTS HAVE NOT BEEN CHANGED BETWEEN THEIR UNLOCKING AND THE
RESTART OF THE PACKAGE.
FOR MAXIMUM LOCKING SECURITY, DO NOT TURN ON THIS OPTION.

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

ENHOPT UNLOCK_FAILED_ACTION=(ON)

O315/A
THE FOLLOWING OPTIONAL PTF WILL ALLOW TO RUN SPECIFIC ACTIONS
WITHOUT USING A PACKAGE EVEN IF THE INVENTORY AREA WOULD NORMALLY
REQUIRE PACKAGE USE

USAGE NOTES :
REPLACE THE (ON,) WITH THE CORRESPONDING VALUE(S) OF THE ACTION(S)
YOU WISH TO ALLOW WITHOUT PACKAGES. IF YOU WISH TO ALLOW MORE THAN
ONE ACTION, ADD THEIR CORRESPONDING VALUES AND REPLACE (ON,) WITH
THE TOTAL

ARCHIVE
- 1
SIGNIN
- 16

DELETE
- 2
TRANSFER - 32

MOVE
- 4
GENERATE - 64

RESTORE
- 8
EXAMPLES :
TO ALLOW ARCHIVE ONLY
CODE (ON,1)
TO ALLOW ARCHIVE AND SIGNIN, CODE (ON,17)
---------------------------------------------------------------------

ENHOPT ALLOW_NON_PKG_ACTIONS=(ON,)

O315/B
THE FOLLOWING OPTIONAL PTF WILL ALLOW TO RUN SPECIFIC ACTIONS IN
A PACKAGE WITHOUT REQUIRING APPROVAL.

USAGE NOTES :
REPLACE THE (ON,) WITH THE CORRESPONDING VALUE(S) OF THE ACTION(S)
YOU WISH TO ALLOW WITHOUT PACKAGES. IF YOU WISH TO ALLOW MORE THAN
ONE ACTION, ADD THEIR CORRESPONDING VALUES AND REPLACE (ON,) WITH
THE TOTAL

ARCHIVE
- 1
SIGNIN
- 4

DELETE
- 2
TRANSFER - 8
EXAMPLES :
TO ALLOW ARCHIVE ONLY,
CODE (ON,1)
TO ALLOW ARCHIVE AND SIGNIN, CODE (ON,5)
---------------------------------------------------------------------

ENHOPT PKG_ACTIONS_NO_APPRVR=(ON,)

O442
APPLY THIS PTF IF YOU WANT TO OPEN THE PKG FILE AND THE INVENTORY
FILES FOR READ-ONLY IF THE PROGRAM DOES A READ OPERATION.
NORMALLY THESE FILES WILL BE AUTOMATICALLY OPENED FOR OUTPUT WHICH
REQUIRES UPDATE ACCESS EVEN FOR USERS WHO ONLY RUN REPORTS OR API
QUERIES.
IF A FILE IS OPENED FOR READ AND LATER IN THE PROCESS AN UPDATE IS
TEMPTED, THEN ENDEVOR WILL CLOSE THE FILE AND REOPEN IT FOR UPDATE
IF THE SECURITY PACKAGE ALLOWS THIS.
---------------------------------------------------------------------

ENHOPT VSAM_INPUT_OK=ON

TRANSFERS COMMENTS AND CCID FROM SCL WHEN TRANSFERRING INSTEAD OF
USING THE COMMENTS AND CCID FROM THE LAST LEVEL.
O484
---------------------------------------------------------------------

ENHOPT XFER_COMMENTS=ON

O1993 : TYPE DEFINITION DEFAULTS
WITH THIS OPTION SET, THE TYPE DEFINITION DEFAULTS WILL CHANGE FROM
FORWARD/ENCRYPTED
BASE TO
REVERSE/UNENCRYPTED

FOR THE ELEMENT AS WELL AS THE COMPONENT LIST

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

ENHOPT DEFAULT_REVERSE=ON

O212 : DO NOT SAVE QUICK-EDIT ACTION OPTION SETTINGS.
STARTING WITH RELEASE 3.8, THE QUICK-EDIT ACTION OPTIONS (AO) ARE
SAVED WHEN CHANGES ARE MADE. SOME CLIENTS REQUESTED THAT THE CHANGES
WERE NOT SAVED TO THE NEXT QUICK-EDIT SESSION.

UNCOMMENT THE FOLLOWING LINE IF YOU DON'T WANT THE CHANGES TO LAST
LONGER THE THE DURATION OF THE QUICK-EDIT SESSION.
---------------------------------------------------------------------

ENHOPT DONT_SAVE_AO=ON

P1957 : STOP READING ARCHIVE FILE WHEN ALL SCL REQUESTS HAVE BEEN

SERVICED EXACTLY ONCE.
WHEN A TRANSFER/RELOAD/LIST OR COPY FROM AN ARCHIVE OR UNLOAD FILE
IS DONE, ENDEVOR WILL CONTINUE TO READ THE ARCHIVE/UNLOAD FILE
(CONCATENATION) UNTIL EOF.

WITH THIS OPTION SET, ENDEVOR WILL TEST THE FOLLOWING 3 CONDITIONS :
- THE SCL MAY CONTAIN NO WILDCARDS,
- THE ELEMENTS MUST BE IN LIFO SEQUENCE IN THE FILE (THE LAST ARCHIVE

MUST BE THE 1ST FILE IN THE CONCATENATION, THE OLDEST ARCHIVE MUST

BE THE LAST IN THE CONCATENATION)
- ALL SCL REQUESTS MUST HAVE BEEN SERVICED ONCE (NO LESS AND NO MORE)
IF ALL ARE TRUE THEN ENDEVOR WILL STOP READING THE ARCHIVE/UNLOAD
FILE WHEN ALL SCL REQUESTS HAVE BEEN SERVICED.

ENDEVOR WILL ISSUE MESSAGES C1G5-53I EXPLAINING IF THIS OPTION WAS
SET AND IF A CONDITION WAS FOUND THAT STOPS THE FEATURE.
---------------------------------------------------------------------

ENHOPT SCAN_STOP=ON

THIS FEATURE ONLY APPLIES TO ENTERPRISE PACKAGES. IF THIS FEATURE IS
ENABLED, THE USE OF THE MVS ONLINE AND BATCH BACKOUT ACTION WILL BE
RESTRICTED FOR ENTERPRISE PACKAGES. ENTERPRISE CCM MUST BE USED TO
BACKOUT OR BACKIN ENTERPRISE PACKAGES.

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

ENHOPT RESTRICT_BACKOUT=ON

OA1499
PDM WILL CLEAR THE OTHER DSN FIELD INFORMATION FROM SCREEN TO SCREEN
THIS FEATURE CAN BE SET TO KEEP THIS FIELD IF DESIRED.

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

ENHOPT KEEP_PDM_OTHERDSN=ON

OC237
DYNAMICALLY BUILT PANELS WILL RETAIN THEIR CASE UPON DISPLAY. THIS
OPTIONAL FEATURE WILL FORCE UPPER CASE FOR THESE PANELS.

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

ENHOPT DYNAM_PANELS_UPPER=ON

OC512
C1G333W WILL BE ISSUED IF $PMR DETERMINES THAT THE PROCESSOR HAS
ALREADY BEEN EXECUTED. THIS OPTIONAL FEATURE WILL EXECUTE THE
PROCESSOR ANYWAY.

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

ENHOPT BYPASS_C1G333W=ON

OC682
THE NORMAL ENDEVOR STOPRC DEFAULT IS 16. THIS PTF CHANGES IT
TO 12 FOR THOSE USERS WHO WANT TO ALWAYS BYPASS SUBSEQUENT
ACTIONS IF ANY ENDEVOR ACTION RECEIVES A RETURN CODE OF 12.

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

ENHOPT SET_STOPRC12=ON

OC763
WHEN ISSUING A MOVE OR TRANSFER, E/MVS WILL CHECK THE PROCESSOR
GROUP DEFINITION FOR THE PROCESSOR NAME AGAINST THE ELEMENTS
MCF PROCESSOR NAME. IF THEY ARE DIFFERENT, C1G147E IS ISSUED.
THIS OPTIONAL PTF WILL BYPASS THE CHECK.

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

ENHOPT BYPASS_C1G147E=ON

OC776
IF A TRANSFER OF AN ELEMENT WAS SUCCESSFUL, BUT THE DELETE
BEHIND OF THE ELEMENT WAS NOT DONE OR THE DELETE PROCESSOR WAS
NOT SUCCESSFUL, THE SUBSEQUENT TRANSFER OF THAT ELEMENT WILL
TRANSFER WILL BEGIN WITH THE ISSUANCE OF THE C1G334W MESSAGE
AND THEN EXECUTE THE DELETE PROCESSOR. THIS OPTIONAL PTF WILL
BYPASS THAT DELETE AND DIRECT THE ACTION TO SOURCE MANAGEMENT
THEN PROCESSOR MANAGEMENT.

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

ENHOPT BYPASS_C1G334W=ON

OC785
THIS PTF IS FOR CUSTOMERS WHO DO NOT HAVE A SECURITY PACKAGE THAT
OPTAINS THE USER FROM THE ASXBUSER FIELD. WITH THIS OPTION TURNED
ON, THE USERID WILL BE OBTAINED FROM THE JCT INSTEAD.

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

ENHOPT NO_SECURITY_USERID=ON

OC1392
DUE TO THE DESIGN OF THE PRODUCT, EXIT-3 WILL ALWAYS BE CALLED
IF EXIT-2 HAS BEEN CALLED.
IN CASE OF QUICKEDIT, SOME CLIENTS REQUISTED THAT EXIT-3 ONLY
BE CALLED IF THE EDIT SESSION WAS NOT CANCELLED AND NO SAVE
COMMAND HAS BEEN EXECUTED PRIOR TO THE CANCEL COMMAND.

THIS OPTIONAL HAS BEEN RESOLVED BY PTF PC1687
PC1687 ALLOWS AN EXIT TO DETECT IF AN ELEMENT HAS BEEN CHANGED
OR NOT USING FLAG ENVDATAC (Y/N)

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

OC1482
THIS OPTIONAL PTF WILL REMOVE THE VERSION/LEVEL SCL SYNTAX FROM
THE SCL GENERATED BY THE BATCH AND PACKAGE ONLINE SCL BUILDING
ROUTINE FOR RETRIEVE.

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

ENHOPT NO_VERSION_LEVEL=ON

LIST ELEMENT WHERE ACM USES BY DEFAULT THE LIBRARY MEMBER NAME IN
THE COMPARISON. SOME CLIENTS HAVE MEMBER NAMES THAT ARE UNEQUAL TO
ELEMENT NAMES AND THEY WOULD LIKE ENDEVOR TO MATCH THE NAME THEY
SEARCH WITH THE ELEMENT NAME RATHER THAN WITH THE MEMBER NAME.

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

ENHOPT ACM_USE_ELEMENT_NAME=ON

OC1928
THIS OPTIONAL PTF WILL ALLOW DUPLICATE SYMBOLS IN PROCESSORS.
DUPLICATE SYMBOLS IN PROCESSORS WILL ISSUE A C1X244E MESSAGE.

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

ENHOPT ALLOW_DUP_SYMBOLS=ON

O2553
THIS OPTIONAL PTF WILL SUPPRESS THE SYSTEM/SUBSYSTEM PROMPTS ON THE
BATCH/FOREGROUND AND PKG ACTION PANELS, EVEN WHEN 'DISPLAY LIST' IS
SET TO Y.
THIS ALLOWS ELEMENTS SELECTION BY CCID/PROCESSOR GROUP ACROSS MORE
THAN ONE SYSTEM/SUBSYSTEM.

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

ENHOPT NO_SYS_SBS_SELECTION_LIST=ON

O2347
THIS OPTIONAL PTF WILL CAUSE ENDEVOR INITIALIZATION TO FAIL IF AN
EXIT FROM C1UEXITS IS FOUND TO BE MISSING.

CAUTION : WHEN YOU SET THIS OPTION MAKE SURE YOU HAVE A LOAD MODULE

CORRESPONDING TO EACH DEFINED EXIT IN C1UEXITS (EVEN THE

"DUMMY" ENTRIES C1UEXT1-C1UEXT7). REMOVE ANY INEXISTENT

EXITS FROM C1UEXITS BEFORE ACTIVIATING THIS OPTION.
---------------------------------------------------------------------

ENHOPT EXIT_LOAD=ON

DAR:
SAVE THE CCID/COMMENT FROM SESSION TO SESSION.
USERS MAY REQUEST THAT THE CCID/COMMENT USED DURING THE PREVIOUS
SESSION OF QUICK EDIT BE SAVED FOR THE NEXT USER SESSION.

UNCOMMENT THE FOLLOWING LINE IF YOU WANT THE CCID/COMMENT SAVED
FROM SESSION TO SESSION.
---------------------------------------------------------------------

ENHOPT SAVE_CCIDCOMM=ON

DISPLAY ACMQ REFERENCE COUNTS - MSGS ACMB24I/25I/26I
WHEN THIS OPTION IS SET, AT THE BEGINNING OF EACH QUICK-EDIT SESSION
ENDEVOR WILL DO AN ACMQ QUERY TO OBTAIN THE NUMBER OF REFERENCES TO
THE ELEMENT BEING EDITED.
LIKEWISE, AFTER EACH ELEMENT PROCESSOR EXECUTION (INCLUDING NOPROC)
AN ACMQ QUERY WILL BE EXECUTED TO DISPLAY THE NUMBER OF TIMES THE
ELEMENT IS REFERENCED IN A COMPONENT LIST.
BY DEFAULT THE QUICK-EDIT OPTION IS ACTIVATED AND THE BATCH OPTION
IS DISABLED (ON,QE).
NOTE : OPTION "ON" (SAME AS ON,QE,BATCH) WILL CAUSE MINIMAL OVERHEAD.
---------------------------------------------------------------------

ENHOPT ISSUE_ELEMENT_REFERENCED_MSGS=ON
OR (ON,QE,BATCH)

ENHOPT ISSUE_ELEMENT_REFERENCED_MSGS=OFF

ENHOPT ISSUE_ELEMENT_REFERENCED_MSGS=(ON,QE)
DEFAULT

ENHOPT ISSUE_ELEMENT_REFERENCED_MSGS=(ON,BATCH)

O2541 CALL EXIT-3 IF EXIT-2 CANCELLED THE ACTION
IN CASE AN EXIT-2 CANCELS THE ACTION (ECBRC=8) THEN NO EXIT-3 CALLS
WILL BE DONE UNLESS THE FOLLOWING OPTION IS TURNED ON.
---------------------------------------------------------------------

ENHOPT EXIT2_FAIL_EXIT3=ON

O495
IN PACKAGE PROCESSING, THE GENPKGID BEFORE EXIT IS ONLY EXECUTED
IF THE PACKAGE ID FIELD IS BLANK AND WE ARE IN A BUILD PACKAGE
SITUATION. THERE MAY BE A SITUATION WHERE THE USER WANTS TO
CHECK THE PACKAGE ID FIELD FOR A VAILD PACKAGE NAME IN A GEN PKGID EXIT BEFORE THE PANEL C1SP2 IS DISPLAYED. THIS
OPTIONAL PTF WILL CHECK TO ENSURE THAT THE OPTION IS '2' FOR
CREATE/MODIFY AND IF SO, INVOKE THE EXIT. IF THE PACKAGE ID
FIELD IS BLANK, THE EXIT WILL BE INVOKED NORMALLY.
---------------------------------------------------------------------

ENHOPT ALWAYS_CALL_GENPKGID=ON

---------------------------------------------------------------------
O458
ISSUE
THE C1G28E MESSAGE FOR ELEMENT NOT FOUND INSTEAD OF
C1G28W.

O53
ISSUE MESSAGE C1G28, SEVERITY LVL "W" FOR ACTIONS:

LIST, RETRIEVE, PRINT, SIGNIN;
ISSUE MESSAGE C1G28, SEVERITY LVL "E" FOR ALL OTHER ACTIONS

OTHER ACTIONS.

O276
ISSUE MESSAGE C1G28, SEVERITY LVL "W" FOR ACTIONS:

LIST, RETRIEVE, PRINT, SIGNIN, TRANSFER;
ISSUE MESSAGE C1G28, SEVERITY LVL "E" FOR ALL OTHER ACTIONS

OTHER ACTIONS.
---------------------------------------------------------------------

ENHOPT MSG_C1G28=1
O458

ENHOPT MSG_C1G28=2
O53

ENHOPT MSG_C1G28=3
O276

O2345
CLIENTS USING A SYMBOLIC AS FOLLOWS WHO WANT THE 1ST PART OF
THE SYMBOLIC TO BE REGARDED AS A SEPARATE SYMBOLIC NEED TO DO
EITHER OF THE TWO THINGS :
1) PREFERRED METHOD : ADD A PERIOD BEFORE THE UNDERSCORE
2) ALTERNATIVE METHODE : APPLY THIS OPTIONAL PTF

SAMPLE :
WHICH=&SYM1_VALUE

WITHOUT THE OPTIONAL PTF APPLIED THE WHOLE OF &SYM1_VALUE IS
REGARDED AS THE SYMBOLIC.
WITH THE OPTIONAL PTF APLIED ONLY &SYM1 IS CONSIDERED TO BE
THE SYMBOLIC.
AS SAID PREVISOULY, THE SAME CAN BE ACCOMPLISHED WITHOUT THE
PTF BY CHANGING THE SYMBOL TO THE FOLLOWING VALUE :
WHICH=&SYM1._VALUE

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

ENHOPT SYMB_UNDERSCORE=ON

O2885

WHEN ELEMENT LOCKING IS SUCCESSFULL, MESSAGES C1G51I AND

C1G56I INFROM THE USER THAT THE ELEMENT HAS BEEN LOCKED FOR

SOME INVENTORY LOCATIONS. SOME CLIENTS FEEL THAT SINCE ELEMENT

LOCKING IS ACTIVE, THESE MESSAGES ARE SUPERFLUOUS.

THIS PTF REMOVES THESE 2 INFORMATIONAL MESSAGES.

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

ENHOPT BYPASS_C1G51=ON

O252
A TRANSFER THAT IS TO ISSUE A MOVE PROCESSOR WILL ALWAYS
EXECUTE A GENERATE PROCESSOR IF A SPECIFIC VERSION.LEVEL IS
TRANSFERRED THAT IS NOT THE CURRENT VERSION.LEVEL.
THE REASON FOR THIS DESIGN IS TO ENSURE THAT THE INTEGRITY
OF THE SOURCE AND EXECUTABLE IS MAINTAINED.

THIS OPTIONAL PTF WILL NOT CHECK THE VV.LL INDICATOR AND EXECUTE
THE PROCESSOR THAT THE PROCESSOR GROUP RECORD DEFINED.

NOTE WELL: THIS OPTIONAL PTF DOES NOT CONFORM TO THE ENDEVOR
DESIGN AND UNDER NO CIRCUMSTANCES WILL CA-ENDEVOR BE RESPONSIBLE
FOR THE LOAD MODULE NOT MATCHING THE SOURCE IF THIS PTF IS
APPLIED.

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

ENHOPT BYPASS_GENERATE_XFER=ON

O276

RESTORE FROM ARCHIVE WITH BYPASS GENERATE OPTION DOES NOT

UPDATE THE MASTER RECORD WITH THE GENERATE DATE AND TIME. THIS

IS BECAUSE THE RESTORE CANNOT GUARANTEE THAT THE OUTPUTS FROM

THE GENERATED ELEMENT WILL BE AVAILABLE OR EVEN CORRECT. THIS

OPTIONAL PTF WILL RESTORE THE GENERATE DATE AND TIME STAMP FROM

THE ARCHIVE FILE IF THAT IS DESIRED. ONE OF THE PROBLEMS THAT

OCCUR FOR NOT HAVING THIS INFORMATION AVAILABLE WOULD BE DURING

THE VALIDATION OF COMPONENTS IN PACKAGES. THE FOOTPRINTS MAY

NOT MATCH UP. UNLOAD/RELOAD WILL UPDATE THE MASTER RECORD

WITH THIS INFORMATION.

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

ENHOPT RESTORE_GENERATE_DATE=ON

O2374

ENDEVOR CHANGES -INC LIBRARIAN CONTROL CHARACTERS TO X'2'INC

PRIOR TO WRITING THE ELEMENT TO A LIBRARIAN BASE/DELTA FILE.

THIS DOES NOT ALLOW THE FILE TO BE USED IN A TRUELY REVERSE

FORMAT. THIS PTF WILL CHANGE THE -INC TO A =INC WHICH IS

RECOGNIZED AS A VALID CONTROL CHARACTER BY LIBRARIAN.

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

ENHOPT LIBR_INC_STMT=ON

O2771

USERS MAY DESIRE TO RESERVE THE OTHER DATASET NAME FIELD IN

EACH USERS PROFILE FOR THE C1SD4 OR C1SD4C PANELS UPON

EACH USE. THIS OPTIONAL PTF WILL ISSUE THE ISPF COMMAND TO

SAVE THE PANEL FIELD IN THE USERS PROFILE. IT WILL BE

RESOLVED TO THE LAST ENTRY UPON EACH DISPLAY OF THE PANEL.

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

ENHOPT RESERVED_OTHERDSN=ON

O846

THIS OPTION WILL CAUSE ENBX1 TO RECOGNIZE == AS A DELIMETER

IN A COPY REPLACE ==XX== BY ==YY== STATEMENT. THIS MAKES IT

COMPATIBLE WITH COBOL2.

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

ENHOPT COPY_COBOL2_REPLACE=ON

O2465

PTF PC1923 CHANGED THE BUILING OF THE MEMBER LIST TO INCLUDE

ALL ELEMENTS WITHIN THE STAGE 1 AND STAGE 2 IF THE BUILD USING

MAP WAS SET TO 'N'. THIS MAY NOT BE DESIRED AT SOME SITES

WHEN USING QUICK EDIT.

THIS OPTIONAL PTF WILL REVERT THE CODE BACK SO THAT BUILD USING

MAP = 'N' WILL ONLY SUPPLY THE LIST OF ELEMENTS FROM STAGE 1

IN QUICK EDIT.

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

ENHOPT QE_BUILD_MAP=ON

O2789

E/NAT USERS HAVE REQUESTED THAT AN ISPF MESSAGE THAT GETS

PROPAGATED THROUGH THE E/NAT PROCESS BE ELIMINATED.

THIS OPTIONAL PTF SUPPRESSES ALL MESSAGES "NN REQUEST(S) BUILT"

REGARDLESS OF THE NUMBER OF REQUESTS BUILT.

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

ENHOPT BYPASS_CIIO92=ON

O322

THIS OPTION APPLIES ONLY TO COBOL INPUT THAT IS BEING EXPANDED

USING THE OPTION 'EXPAND COPY' IN ENBX1 SCL OR USING THE

PARM VALUE EXPANDCOPY ON THE EXEC STATEMENT.

TURNING THIS OPTION ON WILL CAUSE ENBX1 TO INCLUDE THE

ORIGINAL COPY STATEMENT IN THE EXPANDED OUTPUT. THIS COPY

STATEMENT WILL BE A COBOL COMMENT.

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

ENHOPT INCLUDE_ORIGINAL_COPY=ON

O1279

THIS OPTION WILL ALLOW THE EXECUTION OF A PACKAGE THAT CONTAINS

A GENERATE OF AN ELEMENT THAT MAY HAVE BEEN PREVIOUSLY GENERATED

IN ANOTHER PACKAGE.

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

ENHOPT BYPASS_PKMR514E=ON

THE PERFORMANCE OF THE ACMQ DATASET UPDATES IS HIGHLY DEPENDING ON
THE DATA ORGANISATION OF THESE FILES. WE RECOMMEND TO RUN ORPHDEL
(BC1JACMO) AT LEAST ONCE DAILY. IDEALLY THIS SHOULD BE SCHEDULED
OUTSIDE PEAK HOURS.

THE FOLLOWING OPTION CAN ALSO BE LEFT UNCOMMENTED TO INVOKE AN
AUTOMATED REORGANIZATION OF THE ACMQ DATASETS AFTER A MINIMUM NUMBER
OF FILE INSERTS HAVE BEEN REGISTERED. THE ADVANTAGE OF KEEPING THIS
OPTION UNCOMMENTED IS THAT THE FILES WILL BE REORGANIZED BEFORE THE
QUANTITY OF UPDATES CAN CAUSE PERFORMANCE DEGRADATION.

THE AUTOMATIC REORG OF THE FILES WILL ONLY OCCUR AFTER A BATCH ACTION
HAS CAUSED THE INSERT COUNT TO EXCEED THE OPTION VALUE. FOREGROUND
ACTIONS WILL NEVER START THE AUTOMATIC ACMQ FILE REORGANIZATION.

THE START AND END OF THE AUTOMATIC REORG WILL BE SHOWN IN THE JOBLOG
BY MEANS OF THE FOLLOWING TWO WTO MESSAGES :

- AUTO ACMQ FILE REORG STARTED

- AUTO ACMQ FILE REORG ENDED
THE NORMAL ACMQ REORG STATISTICS WILL NOT BE DISPLAYED.

THE RECOMMENDED OPTION COUNT IS 5, BUT VALUES BETWEEN 1 AND 32767
WILL BE ACCEPTED.

THE OPTION SHOULD BE COMMENTED OUT OR SET TO OFF IF NO AUTOMATIC
ORPHDEL IS DESIRED. IF THE OPTION IS TURNED OFF ANY COUNT VALUE WILL
BE IGNORED.
---------------------------------------------------------------------
ENHOPT AUTO_ACMQ_FILE_REORG=(ON,5) (RECOMMENDED)

ENHOPT AUTO_ACMQ_FILE_REORG=OFF
(DEFAULT)

ELEMENT NAME REGISTRATION.
BY DEFAULT, ELEMENT NAME REGISTRATION IS DEFINED AT THE SYSTEM LEVEL
ON THE SYSTEM DEFINITION.

IT GIVES ADMINISTRATORS THE POSSIBILITY TO DENY THE CREATION OF
ELEMENTS (OR ISSUE WARNING OR CAUTION MESSAGES) IF AN ELEMENT WITH
THE SAME NAME ALREADY EXISTS IN THE SAME SYSTEM BUT IN ANOTHER
SUBSYSTEM.

IF OPTION "REGISTER_ACROSS_SYSTEMS" IS TURNED ON, THEN ENDEVOR WILL
ISSUE AN MESSAGE (E/C/W) IF AN ELEMENT GETS ADDED/CREATED AND
ANOTHER ELEMENT WITH THE SAME NAME EXISTS IN ANOTHER UNMAPPED
SYSTEM/SUBSYSTEM.
IF SET TO E, THIS OPTION WILL DENY THE POSSIBILITY TO CREATE A
DUPLICATE NAMED ELEMENT UNLESS IT IS IN THE MAP OF AN EXISTING
ELEMENT.

NOTES:
- INDEPENDENT OF THE OPTION SETTING, ELEMENT NAME REGISTRATION

RESTRICTS THE USE OF THE SAME ELEMENT NAME NO MATTER ITS TYPE.

WITH THIS OPTION TURNED OFF, ELEMENTS WITH THE SAME NAME CAN ONLY

ONLY EXIST IN THE SAME SYSTEM/SUBSYSTEM OR IN ANOTHER SYSTEM (NO

MATTER THE SUBSYSTEM).

WITH THIS OPTION 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 WILL IGNORE ALL OPTION

SETTINGS FOR ELEMENT NAME REGISTRATION AT THE SYSTEM DEFINITIONS.

THE OPTION-SEVERITY SET IN ENCOPTBL WILL RULE OVER ALL SYTEMS

IN ALL THE ENVIRONMENTS NO MATTER WHAT THE ELEMENT NAME

REGISTRATION OPTION SETTINGS IN THE SYSTEM DEFINITIONS CONTAIN.

IF TURNED OFF, THE NORMAL ELEMENT NAME REGISTRATION OPTION SETTINGS

ON THE SYSTEM DEFINITION WILL BE USED TO DETERMINE WHAT RULES APPLY

THE SETTING OF REGISTER_ACROSS_SYSTEMS=(ON,X) HAS NO IMPACT ON THE
WAY DUPLICATE_PROCESSOR_OUTPUT_TYPE_CHECK WORKS. ONE CAN CONTINUE TO
DEFINE ELEMENTS WITH THE SAME NAME IN THE SAME SYS/SBS WITH IF THE
DUPLICATE_PROCESSOR_OUTPUT_TYPE_CHECK SETTINGS ALLOW THIS.
---------------------------------------------------------------------

ENHOPT REGISTER_ACROSS_SYSTEMS=(ON,E) DISALLOW ANY DUPLICATES

ENHOPT REGISTER_ACROSS_SYSTEMS=(ON,C) ALLOW WITH C-LEVEL MSG

ENHOPT REGISTER_ACROSS_SYSTEMS=(ON,W) ALLOW WITH W-LEVEL MSG

ENHOPT REGISTER_ACROSS_SYSTEMS=(OFF)
DEFAULT: USE SETTINGS

ON SYSTEM DEFINITION

SCL_IN_CAST_REPORT.
PRIOR TO RELEASE 4. (SP1), THE CAST REPORT STORED IN THE PKG FILE
CONTAINED ALL SCL STATEMENTS. SINCE THE PKG SCL IS ALSO AVAILABLE IN
OTHER RECORDS, THERE IS NO NEED TO STORE A COPY OF THE SCL IN THE
CAST REPORT SECTION OF THE PACKAGE FILE.
BY DEFAULT THE SCL IS NO LONGER CONTAINED IN THE REPORT RECORDS THAT
ARE STORED IN THE PKG FILE, THIS OFFERS CONSIDERABLE PERFORMANCE
BENEFITS.
CLIENTS THAT WOULD PREFER TO STORE THE SCL PORTION OF THE REPORT IN
THE PKG FILE CAN CONTINUE TO DO SO BY TURNING THE FOLLOWING OPTION
ON.

NOTES:
- IN BATCH, THE CAST REPORT THAT GETS WRITTEN TO FILE C1MSGS WILL

CONTINUE TO LIST THE SCL STATEMENTS, NO MATTER THE SETTING OF

THIS OPTION.
- THIS OPTION DOES NOT DETERMINE IF THE SCL IS STORED IN THE PACKAGE

FILE, NOR DOES IT MAKE IT ANY HARDER TO VISUALIZE THE PACKAGE SCL.

THE OPTION WILL, BY DEFAULT, ONLY SUPPRESS THE NEEDLESS DUPLICATION

OF THIS DATA.
---------------------------------------------------------------------

ENHOPT SCL_IN_CAST_REPORT=ON
DEFAULT VALUE IS OFF

CAST_INSPECT_EXIT2
WITH RELEASE 4. ENDEVOR CALLS EXIT2 TO DO CCID VALIDATION DURING
CAST AND INSPECT.
NOT ONLY ENDEVOR'S CCID VALIDATION PROGRAM CAN GET CALLED BUT
USER EXITS-2 CAN ALSO BE CALLED DURING CAST/INSPECT WITH THIS
OPTION TURNED ON. THIS ALLOWS USER EXITS-2 TO ALLOW OR TO FAIL
ACTIONS DURING CAST/INSPECT.

IMPORTANT NOTES:
1) APART FROM THE USUAL EXIT7 POINTS, ONLY USER EXITS-2 WILL

BE CALLED WHEN THIS OPTION IS ACTIVATED DURING CAST AND INSPECT.

IT IS IMPORTANT TO NOTICE THAT USER EXITS-3 WILL NOT BE CALLED!
2) FIELD ECBPKG WILL CONTAIN THE VALUE "I" WHEN CALLED DURING CAST OR

INSPECT TO ALLOW THE EXIT TO RECOGNIZE THIS SPECIFIC CONDITION.

THE VALUES FOR ECBPKG CAN NOW BE :

Y - EXECUTION OF ACTION WITHIN PACKAGE

N - EXECUTION OF ACTION OUTSIDE PKG.

I - NOT RUNNING AN ACTION, BUT DOING CAST/INSPECT VALIDATION CALL

CAST/INSPECT VALIDATION CALL
---------------------------------------------------------------------

ENHOPT CAST_INSPECT_EXIT2=ON

O3265 - BACKOUT_PROMPT
WHEN AN ELEMENT IS PART OF A BACKED OUT PACKAGE AND THIS OPTION IS
SET ON, THAN ANY FOREGROUND DISPLAY OR ACTION OF THIS ELEMENT WILL
RESULT IN A CAUTIONARY POP UP PANEL BEING DISPLAYED. AT THIS PANEL,
YOU CAN DECIDE TO CONTINUE (ENTER) OR CANCEL (PF3) THE ACTIVITY.

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

ENHOPT BACKOUT_PROMPT=ON

MSGSEVERITY TABLE

THE FOLLOWING SECTION OF THE OPTIONS TABLE ALLOWS TO CHANGE THE
MESSAGE SEVERITY FOR A NUMBER OF SPECIFIED MESSAGES.
YOU CAN LEAVE THE OPTION UNSPECIFIED (COMMENTED OUT) WHICH MEANS THAT
THE DEFAULT MESSAGE SEVERITY (AS SHOWN) WILL BE ISSUED.

YOU CAN ALSO SELECT TO ISSUE THE OTHER ALLOWABLE MESSAGE SEVERITIES
(AS SHOWN) ON THE SAMPLE STATEMENT.
IF YOU SELECT A MESSAGE SEVERTY THAT IS NOT ALLOWED THE ASSEMBLY OF
THE OPTIONS TABLE WILL FAIL.

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

MSGSEVERITY MSGID
DEFAULT
- POSSIBLE - REFERENCE
---------------------------------------------------------------------

ENHOPT MSGSEVERITY_C1G295=C
W/C
O716

ENHOPT MSGSEVERITY_SMGR116=C
W/C/E
O24/557

ENHOPT MSGSEVERITY_C1X13=C
W/C
O51

ENHOPT MSGSEVERITY_IMGR9=E
W/E
O53

ENHOPT MSGSEVERITY_C1G119=E
W/E
O52

C/E
O649

W/E
O893

ENHOPT MSGSEVERITY_ENBX43=C
W/C
O2162

ENHOPT MSGSEVERITY_FPVL4=E
W/E
O2213

W/C
O2677

C/E
O2833

ENHOPT MSGSEVERITY_ENBE27=W
I/W
O2329

W/E
O2816

ENHOPT MSGSEVERITY_C1BMX21=E
W/E
O3542

ENHOPT MSGSEVERITY_ENBP1=W
W/E
PKG DELETE

SUPER USER TABLE

ENDEVOR WILL LET USERIDS DEFINED AS "SUPER-USER" UPDATE AND DELETE
PACKAGES THAT ARE IN IN-EDIT STATUS EVEN IF THE PACKAGE IS NOT
SHARABLE AND IF THAT PACKAGE DOES NOT BELONG TO THE SUPER-USER.
TO DEFINE ONE OR MORE SUPER-USERS, CODE ONE OR MORE MACRO STATEMENTS
AS BELOW IN THE SAMPLE. IF NO SUPER-USERS HAVE BEEN CODED, THIS
OPTION WILL NOT BE ACTIVATED.
THE USER-IDS MUST BE SPECIFIC, WILDCARDS ARE NOT ALLOWED.
NOTE: ONCE THE PACKAGE HAS BEEN CAST, ONLY APPROVERS CAN HANDLE

THESE PACKAGES. SUPER-USERS CAN NOT UPDATE PACKAGES THAT HAVE

APPROVERS IF THEY ARE NOT ALSO AN APPROVER OF THE PACKAGE.
---------------------------------------------------------------------

ENHOPTSU USER1

ENHOPTSU (USER2,USER3)

DYNAMIC APPROVERS

A PACKAGE APPROVER CAN DYNAMICALLY ADD OTHER APPROVERS TO A PACKAGE
IF THE DYNAMIC APPROVERS OPTION IS ENABLED. IF THE OPTION IS LEFT
DISABLED, THE DYNAMIC APPROVER FEATURE WILL BE SUPPRESED.

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

ENHOPT DYNAMIC_APPROVERS=ON

GENERATE THE TABLE. MUST BE LAST ENTRY IN TABLE.

ENHOPT GEN
END
6.2 The Features Discussed in This Chapter

Endevor provides you with several optional features. After you have installed
and verified the base Endevor system, your site can incorporate other, relevant
components of Endevor.
The features discussed in this manual include the following:
Feature
Description
CCID definition data set
This option allows you to

predefine the CCIDs to be used
at your site.
SMF interface

record each action and each
security violation that occurs
during Endevor processing.
Interface for AllFusion

CA-Panvalet
This option allows you to use

AllFusion CA-Panvalet as the
source library manager. The
option is also necessary if you
want to expand imbedded
++INCLUDE statements.
++CONTROL password
This option is used when you

want Endevor to supply the
++CONTROL password for
each AllFusion CA-Panvalet
library that Endevor accesses.
Interface for CA-AllFusion

CA-Librarian
This option allows you to use

CA-AllFusion CA-Librarian as
the source library manager.
The option is necessary if you
want to expand imbedded INC
statements.
Alternate ID support

protect Endevor-controlled
data sets from direct update by
individual users.
Feature
Description
Site-defined Symbolics

reference user-defined,
site-wide symbolics from
within data set name
specifications for base, delta,
source output, and include
libraries, as well as from
processors.
Parmlib data set
This option identifies the

Parmlib data set used at your
site. This library contains your
site's Type Sequence member if
one is defined at your site.
Type Sequence member
Name of the member within

the Parmlib data set that
defines your site type
processing sequence.
Tip: Enabling some of these features may require that you redefine the
Endevor Defaults Table. To expedite the installation process, read through all
sections before making any changes. Then, when you are finished, you can
make all necessary changes at one time.
6.3 The Features Not Discussed in this Chapter
6.3 The Features Not Discussed in this Chapter

Endevor offers several other optional features, which are discussed in detail in
other guides. See these guides for the appropriate installation information:
For information about . . .
See this manual
User customizable dialog

defaults
Dialog Options Fields in the chapter

The ISPF Dialog Options
Configuration Table.
Site Defaults Table selection exit

(ENUXSITE)
Using an Alternate Defaults Table in

the chapter The Alternate Defaults
Table.
Package processing
Packages Guide
Security (all types)a
Security Guide
User exitsb
Exits Guide
Reports
Reports Guide
API (Application Program

Interface)
API Guide
CSV(Comma Separated Value

Utility)
Utilities Guide
PDM (Parallel Development

Option)
Parallel Development Option Guide
ROSCOE
Interface for CA-Roscoe Guide
PITR (Point-in-Time Recovery)
Utilities Guide
Information/Management
Interface
Interface for IBM Tivoli Information

Management Administration Guide
DB2
Endevor for DB2 Installation Guide

and Endevor for DB2 User Guide
Endevor/DB-MVS Bridge
Endevor to CA-Endevor/DB Bridge

Administrator Guide
If you are using the security feature, be sure the security tables are copied
into the appropriate authorized library.
a
b If you are using user exits, be sure they are copied into the appropriate
authorized library.
6.4 The CCID Definition Data Set

If you want to use CCID validation, you must build a CCID definition data
set. Before you can build the data set, though, you need to specify a CCID
validation data set name in the Defaults Table, using the CIPODSN parameter.
See the chapter The Defaults Table, for the definition of the CIPODSN
parameter.
6.4.1 Install the CCID Definition Data Set

There are three steps involved in installing the CCID definition data set.
Step
Action
Allocate the data set.
Initialize the data set.
Add the data set name to the

6.4.2 Step 1: Allocate the Data Set

Allocate the CCID validation data set using the standard ISPF data set
utilities--option 3.2 from the ISPF/PDF Primary Option Menu. The data set
must have the following attributes:
Parameter
Value
LRECL=
80
RECFM=
FB
DSORG=
PS
BLKSIZE=
Any multiple of 80
The data set name you use must be the same as that specified for the
CIPODSN parameter in the Defaults Table. The data set name can be any valid
name that conforms to your site's naming conventions.
6.4.3 Step 2: Initialize the Data Set

You can initialize the CCID validation data set by copying a Computer
Associates-supplied template. Because Endevor requires information to be
placed in certain columns, it is recommended that you copy member
SAMPCIPO into the data set allocated in Step 1. By using this member as a
template, you can ensure that the fields in the data set are positioned in the
correct columns.
Use the standard ISPF copy utility--option 3.3 on the ISPF/PDF Primary
Option Menu--to copy SAMPCIPO from the sample JCL library
(iprfx.iqual.JCLLIB, created during Step 2 of the base installation process) into
the data set.
Use the ISPF edit service to tailor the data set to meet the requirements of your
site. See the Administrator Guide for a description of the contents of the data
set.
6.4.4 Step 3: Add the Data Set Name to the Defaults Table
After you have allocated and initialized the CCID validation data set, you need
to add the data set name to the Endevor Defaults Table. To do this, add the
valid data set name to the CIPODSN parameter; see below:
Col
1
Col
16
C1DEFLTS TYPE=MAIN,
.
.
.
CIPODSN=,
.
.
.
Col
72
CCID VALIDATION DATASET NAME
See the discussion of the Defaults Table in the chapter The Defaults Table,
for additional information about editing the table.
Do not update the CIPODSN parameter in the Defaults Table before allocating
the CCID validation data set. If CIPODSN contains a non-null entry, Endevor
assumes that the entry is a data set name and looks for that data set during
initialization. If Endevor cannot find the data set, it generates an error
message. Therefore, before using Endevor, be sure that the CCID validation
data set is allocated and defined appropriately.
6.5 The SMF Interface

6.5.1 Overview
The SMF interface records each action and each security violation that occurs
during Endevor processing. SMF recording is done on an
environment-by-environment basis. Therefore, you can selectively enable SMF
recording for each of your environments.
For information about SMF recording, see the Administrator Guide.
6.5.2 Set the SMF Parameters in the Defaults Table

To request this interface, you must modify the Endevor Defaults Table to
include the appropriate SMF parameters. Do this by specifying the following
parameters:
SMFREC#= in the TYPE=MAIN macro
SMFACT= and SMFSEC= in the TYPE=ENVRNMNT macro
See the discussion of the Defaults Table in the chapter The Defaults Table for
additional information about editing the table.
6.5.3 TYPE=MAIN Parameters

Specify the SMFREC# parameter in the TYPE=MAIN portion of the Defaults
Table:
Col
1
Col
16
C1DEFLTS TYPE=MAIN,
.
.
.
SMFREC#=,
.
.
.
Col
72
SMF RECORD NUMBER
This is the SMF record number assigned to SMF records written by Endevor at
this site. See the TYPE=MAIN parameter definitions in the chapter The
Defaults Table, for more information about this SMF parameter.
Tip: Talk to a systems programmer at your site to ensure that you are indeed
collecting the SMF records related to the record number specified in the
SMFREC# parameter. Recording records is controlled in
SYS1.PARMLIB(SMFPRMxx).
6.5.4 TYPE=ENVRNMNT Parameters

You should specify at least one of the following SMF parameters in the
TYPE=ENVRNMNT portion of the Defaults Table:
Col
1
Col
16
C1DEFLTS TYPE=ENVRNMNT,
.
.
.
SMFACT=N,
SMFSEC=N,
.
.
.
Col
72
SMF ACTIVITY OPTION (Y/N)

SMF SECURITY OPTION (Y/N)
X
X
These parameters are defined as follows:

Parameter
Definition
SMFACT
Indicates whether Endevor

should write out SMF Action
Records. Set this parameter to Y
if you want the Action Records
written out. Otherwise, set the
parameter to N.
SMFSEC
Indicates whether Endevor

should write out SMF Security
Records. Set this parameter to
Y if you want the Security
Records written out. Otherwise,
set the parameter to N.
See the TYPE=ENVRNMNT parameter definitions in the chapter The Defaults

Table, for more information about these SMF parameters.
6.6 The Endevor AllFusion CA-Panvalet Interface

If your site is (or will be) using AllFusion CA-Panvalet as a source library
manager, 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 or
a PDS when the interface is enabled.
Note: Be sure that the AllFusion CA-Panvalet installation does not suppress
level checking on the AllFusion CA-Panvalet UPDATE ALL command.
6.6.1 Link-Edit the Access Module

There are three steps involved in link-editing the AllFusion CA-Panvalet access
modules to Endevor AllFusion CA-Panvalet Interface modules:
Step
Action
Edit member BC1JPAN (in the JCL

library) to include the name of
your AllFusion CA-Panvalet load
library.
Link-edit the PAM module, using

BC1JPAN. Place the output load
module that was created by this
job into CONLIB.
Redefine the Defaults Table, if

necessary, to specify PV in the
LIBENV parameter.
6.6.2 Step 1: Edit BC1JPAN

Tailor the BC1JPAN JCL to provide the correct name of your AllFusion
CA-Panvalet load library on the PAMLIB DD statement. BC1JPAN JCL, which
is supplied on the installation tape, is shown below.
// ( 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 BC1JPAN

If you have not already done so, copy your JOBCARD member to the
beginning of BC1JPAN. Then submit the job for execution. BC1JPAN link-edits
the PAM module and places the output load module in CONLIB.
6.6.4 Step 3: Set the AllFusion CA-Panvalet Parameters in the

Defaults Table
Redefine the Endevor Defaults Table, if necessary, to specify the value PV in
the LIBENV parameter (in the TYPE=MAIN macro). Update the LIBENVP
parameter to specify that AllFusion CA-Panvalet is installed at your site.
Col
1
Col
16
C1DEFLTS TYPE=MAIN,
.
.
.
LIBENV=PV,
LIBENVP=Y,
.
.
.
Col
72
X
X
6.7 The ++CONTROL Password Interface

Endevor provides a ++CONTROL password feature, which is available to the
Endevor for AllFusion CA-Panvalet Interface. This feature is optional, and
allows Endevor to supply the ++CONTROL password for each AllFusion
CA-Panvalet library that will be accessed by Endevor. The password interface
is intended for AllFusion CA-Panvalet libraries that are currently
password-protected.
6.7.1 Install the ++CONTROL Password Interface

There are three steps involved in installing the ++CONTROL password
interface.
Step
Action
Edit member BC1JCNTL.
Run BC1JCNTL.
Copy the output into the Endevor

authorized library.
6.7.2 Step 1: Edit BC1JCNTL

To install the ++CONTROL password interface, you need to provide the
AllFusion CA-Panvalet library data set name and password for each library
that is password-protected. Use member BC1JCNTL, which is supplied in the
installation JCL library, to do this. The JCL contains the instructions you need
to define each library and password.
The BC1JCNTL JCL is shown below. 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)
//SYSUT1
//SYSUT2
//SYSUT3
//SYSPUNCH
DD DUMMY
//SYSPRINT
DD SYSOUT=
//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 DSN
CTLCODA
DC
CL8'' <=== PASSWORD (8 CHAR MAX)
DC
CL12' '

PANLIBB
DC
CL44'panprfx.PANQUAL.PANLIBB' <=== PANLIB DSN
CTLCODB
DC

PANLIBC
CTLCODC

PANLIBD
CTLCODD
DC
CL12' '
DC
DC
DC
CL44'panprfx.PANQUAL.PANLIBC' <=== PANLIB DSN

CL12' '
DC
DC
DC
CL44'panprfx.PANQUAL.PANLIBD' <=== PANLIB DSN

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)
//SYSUT1
6.7.3 Step 2: Run BC1JCNTL

If you have not already done so, copy the JOBCARD member (in the JCL
library) 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, you
need to install the AllFusion CA-Librarian Interface. This interface allows you
to 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 entire
member, ignoring--but preserving--AllFusion CA-Librarian sequence numbers.
6.8.1 External and Internal Libraries

The AllFusion CA-Librarian data sets can be used as external libraries; for
example, as development libraries, INCLUDE libraries, or target libraries.
It is not recommended that you use AllFusion CA-Librarian data sets as
internal (base and delta) libraries, for performance and external usability
issues. If you do use these data sets as Endevor base and delta libraries, note
that members written into the libraries are always stored with sequence
numbers in columns 81-86, regardless of the type of language used. This is
done to protect Endevor information.
6.8.2 Set the AllFusion CA-Librarian Parameters in the Defaults Table

Redefine the Endevor Defaults Table, if necessary, to accommodate for the
AllFusion CA-Librarian Interface:
Specify the value LB in the LIBENV parameter (in the TYPE=MAIN
macro).
Update the LIBENVP parameter to specify that AllFusion CA-Librarian is
installed at your site.
Specify the name of the AllFusion CA-Librarian load module for your site
in the LIBRPGM parameter. (In the example below, the load module name
is AFOLIBR, the default name delivered by CA-AllFusion CA-Librarian.
Col
1
Col
16
C1DEFLTS TYPE=MAIN,
.
.
.
LIBENV=LB,
LIBENVP=Y,
LIBRPGM=AFOLIBR,
.
.
.
Col
72
X
X
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 sequence
columns for AllFusion CA-Librarian, and preserves all 80 columns of data (as
applicable), it is not absolutely necessary to customize the interface at
installation.
If you do not require the Sequence Update facility (SEQUPD) of
AllFusion CA-Librarian, you do not need to customize Endevor to run the
Endevor AllFusion CA-Librarian Interface.
If you need to control the sequence column numbers by type (if you are
using the Sequence Update facility), you must customize your installation.
Customization allows you to keep the AllFusion CA-Librarian members in
external AllFusion CA-Librarian data sets, which may be updated by using
imbedded sequence numbers.
For example, some sites have families of programs that are all updated by a
common set of changes to a central copy of a particular type of program, such
as a payroll program with several variants. The same set of changes can be
applied to all programs by using the AllFusion CA-Librarian SEQUPD facility.
In this example, customization would be required, as the client would need to
retain control of the sequence number columns.
6.8.4 Considerations When Customizing

If you decide to customize the Endevor AllFusion CA-Librarian Interface for
your site, you must consider the following:
Endevor must know the sequence columns for the element type being
processed.
Endevor must preserve the original set of sequence numbers within the
element, so subsequent sequence number updates will match correctly.
Endevor must always set the sequence columns when writing the element
to an external AllFusion CA-Librarian data set, so AllFusion CA-Librarian
will allow you to use these sequence columns for SEQUPD processing.
This procedure informs AllFusion CA-Librarian that these specific columns
are available, which in turn prevents automatic renumbering by AllFusion
CA-Librarian.
You must ensure that any element types customized for sequence number
processing have valid, ascending numeric sequence numbers within the
element.
6.8.5 Customize Your Site for the AllFusion CA-Librarian

There are two steps involved in customizing your installation for the Endevor
AllFusion CA-Librarian Interface.
Step
Action
Assemble and link-edit a language

definition table to define the sequence
columns by internal language for
your installation.
Define distinct Endevor types for

those elements that will use SEQUPD
processing.
6.8.6 Step 1: Define Sequence Number Columns

Use member BC1JLIBR, which is supplied in the installation JCL library, to
define sequence number columns by language.
The BC1JLIBR JCL is shown below.
//(JOBCARD)
//-------------------------------------------------------------------
//

//
(C) 22 COMPUTER ASSOCIATES INTERNATIONAL, INC. (CA)

//

// 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=248K,
//
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),
//
//SYSUT1
DD UNIT=tdisk,SPACE=(TRK,(5,5))
//SYSUT2
//SYSUT3
//
// 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=248K,
//
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)
//SYSUT1
6.8.7 Edit the BC1JLIBR JCL

You need to edit BC1JLIBR to meet the requirements of your site. Note the
highlighted lines in the JCL. Edit these lines as follows:
SYSLMOD DD--Replace iprfx.iqual.conlib with the CONLIB data set name
you are using.
C1LIBRSQ lines--Each C1LIBRSQ line defines the sequence number
columns to be used for a particular internal language type. Enter the
information required by your organization. Each line must specify a
language (three characters in length, indicated by xxx), as well as two
column numbers--a beginning column number (n1) and an ending column
number (n2). You must enter one line per language. You can enter as
many lines as necessary.
The language types are matched against the PV/LB LANG field on the
Type Definition panel (see the Administrator Guide).
The list below reflects the language codes Endevor uses (see also the Note
below):
Language
Code
ASM (Assembler)
GOF
COB (COBOL)
JCL
DAT (Data)
PLF
Language
Code
FOR (FORTRAN)
PLI
FRG (FORTRAN G)
RPG
FRH (FORTRAN H)
TXT
GIS
VSB
The examples below illustrate acceptable C1LIBRSQ lines:

C1LIBRSQ LANG=COB,SEQCOLS=(1,6)
In this example, the language type is COBOL and the sequence number
columns are 1 through 6.
C1LIBRSQ LANG=ASM,SEQCOLS=(73,8)
In this example, the language type is Assembler and the sequence number
columns are 73 through 80.
Any languages not specified in the JCL are stored with sequence columns 81
through 86.
Note: If your site uses language codes other than those listed above, contact
Endevor Technical Support. An optional patch is available that allows you to
modify the language codes in the JCL to accommodate the codes you are
using.
6.8.8 Step 2: Define Endevor Types

You must determine which Endevor types require the AllFusion CA-Librarian
SEQUPD capability when you define element types for a system. These types
require specific information to be entered on the Type Definition panel (see the
Administrator Guide), as follows:
The PV/LB LANG field must match one of the languages defined in the
language definition table.
The COMPARE FROM and COMPARE TO fields must include the
sequence column fields defined for that language.
Specify N for EXPAND INCLUDES, if the source output library is a
AllFusion CA-Librarian data set. (Expanding INCLUDES makes the
sequence numbers invalid.)
Note: If the language does not match or the sequence columns are not
included within the compare columns (or both situations occur), Endevor
stores the sequence numbers in columns 81 through 86 when writing to
external AllFusion CA-Librarian data sets.
6.8.9 Points to Remember

When defining types for the Endevor AllFusion CA-Librarian Interface, keep in
mind the following points.
For element types that are customized for the Endevor AllFusion CA-Librarian
Interface:
Avoid EXPAND INCLUDES during add or retrieve processing where the
target is a AllFusion CA-Librarian data set. Expanding INCLUDES makes
the sequence numbers invalid.
Ensure that members have valid sequence numbers in the sequence
columns. If the numbers are invalid, AllFusion CA-Librarian rejects
members during Endevor retrieve processing.
If an Endevor member has invalid sequence numbers, retrieve that
member 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 be
aware 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 happen
in 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-Librarian
sequence columns, to avoid sequence number edit rejections by AllFusion
CA-Librarian.

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 Master
Control Files, the package data set, and processor output libraries) from direct
update by users.
When using alternate ID support, a separate administrator's ID is defined to
Endevor. This separate--or alternate ID--is granted update authority for the
Endevor libraries. When Endevor needs to update these libraries, the system
does so using the authorization assigned to the alternate ID.
By defining an alternate ID and assigning it specific update authorization, you
can prevent a user from inadvertently updating particular libraries.
6.9.1 Implement Alternate ID Support

There are two steps involved in implementing the alternate ID support feature.
Step
Action
Redefine the Endevor Defaults Table

to accommodate for alternate ID
support.
Use your site's security system to

build profiles to protect the libraries,
and grant update authority to the
alternate (administrator's) ID for those
libraries.
6.9.2 Step 1: Set the Alternate ID Parameters in the Defaults Table

You need to redefine the TYPE=MAIN macro in Endevor Defaults Table to
include (or update) the parameters highlighted below:
Col
1
Col
16
C1DEFLTS TYPE=MAIN,
.
.
.
RACFGRP=security group name,
RACFPWD=password,
RACFUID=userid,
.
.
.
Col
72
X
X
X
Provide information for each parameter as follows:

RACFGRP--Indicate the name of the security group with which the
alternate ID is associated. This parameter is optional.
RACFPWD--Indicate the password for the alternate ID defined. This
parameter is optional.
RACFUID--Indicate the user ID required for alternate ID support.
6.9.3 Step 2: Build a Security Profile for Endevor Libraries

See your site's security material, or check with your Security Administrator, to
build the profiles required to protect the Endevor libraries and grant the
appropriate 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 reference
within dataset name specifications for base, delta, source output, include
libraries, and processors (that is, you can use them wherever you can use
Endevor symbolics). At execution time, any site-defined symbolics referenced
by 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 processor
symbolic (and processor symbolic override) take precedence.
When Endevor is initialized, the site-defined symbolics are placed into
memory. When Endevor is terminated, the site symbolic storage is released.
If more than one Endevor task is executing, each task has its own discrete site
symbolic storage.
To implement the use of site-defined symbolics, you must define the symbolic
and its data value in a table that is assembled and linked into an authorized
load library. Once this is done, you need to update the SYMBOLTBL
parameter in the C1DEFLTS table with the name of the site-defined symbolics
table. These actions are described below.

Use the following format to define a symbolic and its data value in the
site-defined symbolics table:
$ESYMBOL SYMNAME=#symbolname,SYMDATA=symbolvalue
Item
Description
symbolname
The symbol name must begin with the # character and is 1 to

11 characters in length. The # indicates that the symbol is
defined in the site-defined symbolics table.
symbolvalue
The data value associated with the site symbolic is 1 to 70

characters in length, with no restrictions on the content of
the 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 the
site-defined symbolics table.
6.10.2 Updating C1DEFLTS

After creating the symbolics table, update C1DEFLTS to reflect the table name.
Use the SYMBOLTBL= parameter to define the table name as shown below:
SPFEDIT=SPFEDIT,
SYMBOLTBL=ESYMBOLS,
SYSIEWL=SYSIEWLP,
MIXEDFMT=(DESCRIPTION,COMMENT),
UIDLOC=(1,7),
VIOUNIT=VIO,
WRKUNIT=SYSDA,
RACFUID=NDVUSER,
RACFGRP=NDVALT,
PKGCSEC=N,
PKGCVAL=O,
PKGSEC=ESI,
PRBLKSZ=,
PRLNKSZ=(896K,96K),
PRLSTSZ=1,
MODHLI=BST
ENVNAME=D4,
ENVTITL='Development Rel 4.',
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
The Site Information from C1DEFLTS panel displays the parameter value in
the SYMBOLICS Table field highlighted below:

Customer Name.....
-----------------Site ID...........
Release...........
Environments......
Userid Start......
Userid Length.....
Batch ID..........
SPFEDIT QNAME.....
SYSIEWL QNAME.....
Authorized Tables.
Gen in place/SO...
CA-LSERV JRNL SBS.
PITR Journal Grp..
SYMBOLICS Table...
Computer Associates Inc., Endevor Development

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

Access Table......
ASCM.....
B4C
SMF Record Number. 23
DB2......
4
EDITELM..
1
Library Program... LIBRARV
ELINK....
7
VIO Unit.......... VIO
ESSI.....
1
INFO.....
SPFEDIT
Work Volser.......
LIBENV...
SYSIEWLP
NETMAN...
IGNORE
MODHLI............ BST
PDM......
N
Signout on fetch.. N
PROC.....
ELINK XLTE TBL....
Mixed Format...... COMMENT DESCRIPTION
ESYMBOLS
(Press Enter for Next
Y
Y
Y
Y
N
N
Y
N
Y
Y
Panel)

This library contains the Type Sequence member, if one is defined at your site.
To allocate the Parmlib data set, the administrator edits the BC1JEPRM
member in the site's AllFusion Endevor JCLLIB data set, and then executes the
batch job. To define the Parmlib data set to AllFusion Endevor, the
administrator adds the PARMLIB= parameter to the C1DEFLTS table.
6.11.1 Defining the Parmlib in the C1DEFLTS

The PARMLIB= parameter must be added to the C1DEFLTS table. In the
example below, the Parmlib data set name is BST.ENDEVOR.PARMLIB. This
example also shows that the type sequence member is named ETYPESEQ.
Col 1
Col 16
Col 72
C1DEFLTS TYPE=MAIN,
.
.
.
PARMLIB='BST.ENDEVOR.PARMLIB',
TYPESEQMBR=ETYPESEQ,
.
.
.
X
X
The environment site information panel displays Parmlib information on the

second screen of the Site Information from C1DEFLTS panel. The following
panel 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...
--------------------------Element Catalog............
Package Control File.......
Installation Macro Library.
CCID Validation Data Set...
ACM Index Root Data Set....
ACM Index Xref Data Set....
Control Data Set Names --------------------------BST.DEVEL.ELMCATL

BST.DEVR4.VSAMRLS.PACKAGE
BST.P4B4S2.MACLIB
BST.NDVR4.ACMROOT
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 this
option enabled, SCL and API element actions are executed in type sequence
order defined at the site level.
6.12.1 Implementing Global Type Sequencing

To implement Global Type Sequencing, the AllFusion Endevor admistrator
creates a type processing sequence file. The order of the type records in the
Type Sequence member represents the processing sequence.
To assist in building the Type Sequence member, a utility helps the
administrator to define type sequencing for the site. After the file is in the
desired order, the administrator copies the file to the site's Type Sequence
member file within Endevor's Parmlib data set. To define the Type Sequence
file to AllFusion Endevor, the administrator adds TYPESEQMBR= to the
C1DEFLTS table.
For details on creating the type sequence file, see the chapter "Global Type
Sequencing."
6.12.2 Defining the Type Sequence Member in the C1DEFLTS

The TYPESEQMBR= parameter must be added to the C1DELTS table. For
details about defining the TYPESEQMBR= parameter in the C1DEFLTS, see
Defining the Parmlib in the C1DEFLTS. Note that in order to implement type
sequencing, the PARMLIB= parameter must be defined, because the Type
Sequence file is contained in the PARMLIB data set.
Chapter 7. Site Symbolics
Chapter 7. Site Symbolics 7-1

Site-defined symbolics are user-defined symbolic values that you reference
within dataset name specifications for base, delta, source output, include
libraries, and processors (that is, you can use them wherever you can use
Endevor symbolics).
7.2 Site Symbolics Overview

The site symbolics facility enables you to define global symbols that can be
used in type and processor definitions to reference data set name specifications
for base, delta, source output, include libraries, and processors (that is, you can
use them wherever you can use Endevor symbolics). Thus, commonly
referenced data sets can be defined in a single location significantly easing
maintenance. At execution time, all site symbolics referenced by a processor
are stored with the processor symbolics in the component data. If a site
symbolic is also specified as a processor symbolic, the processor symbolic (and
processor symbolic override) take precedence.
When Endevor is initialized, the site symbolics are placed into memory. When
Endevor is terminated, the site symbolic storage is released. If more than one
Endevor task is executing, each task has its own discrete site symbolic storage.
To implement site symbolics, you must define the symbolic and its data value
in a table that is assembled and linked into an authorized load library. Once
this is done, you must update the SYMBOLTBL parameter in the C1DEFLTS
table with the name of the site symbolics table. These actions are described
below.
Note: Site symbolics are required only if you are using USS HFS path name
specifications for element type base or source output file definitions.
Otherwise, site symbolics are optional.

Before defining the site symbolics, remember:
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 symbolic
name. For example, site symbolic #VENDORLB is referenced as:
&#VENDORLB
SYMDATA values must be enclosed in quotes if the value contains
ampersands 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 be

doubled. 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 site
symbolics table:
$ESYMBOL SYMNAME=#symbolname,SYMDATA=symbolvalue
symbolname
The symbol name must begin with the # character and is 1 to 11 characters
in length. The # indicates that the symbol is defined in the site-defined
symbolics table.
symbolvalue
The data value associated with the site symbolic is 1 to 70 characters in
length, with no restrictions on the content of the 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 member BC1JSYMT to create the site
symbolics table.
7.2.2 Updating C1DEFLTS

After creating the symbolics table, update C1DEFLTS to reflect the table name.
Use the SYMBOLTBL= parameter to define the table name as shown below.
SPFEDIT=SPFEDIT,
SYMBOLTBL=ESYMBOLS,
SYSIEWL=SYSIEWLP,
MIXEDFMT=(DESCRIPTION,COMMENT),
UIDLOC=(1,7),
VIOUNIT=VIO,
WRKUNIT=SYSDA,
RACFUID=NDVUSER,
RACFGRP=NDVALT,
PKGCSEC=N,
PKGCVAL=O,
PKGSEC=ESI,
PRBLKSZ=,
PRLNKSZ=(896K,96K),
PRLSTSZ=1,
MODHLI=CA
ENVNAME=TSTSMPL
ENVTITL='Endevor Administraion Application'.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
The Site Information from C1DEFLTS panel displays the parameter value in
the SYMBOLICS Table field.

Customer Name.....
-----------------Site ID...........
Release...........
Environments......
Userid Start......
Userid Length.....
Batch ID..........
SPFEDIT QNAME.....
SYSIEWL QNAME.....
Authorized Tables.
Gen in place/SO...
CA-LSERV JRNL SBS.
PITR Journal Grp..
SYMBOLICS Table...
SUPPORT 4. BETA/2

Function Controls -------------------- Options
Access Table...... BC1TNEQU
ACM...... Y
B4C
SMF Record Number.
DB2...... N
2
QuickEdit Y
1
Library Program...
ELINK.... N
7
VIO Unit.......... SYSDA
ESI...... Y

INFO..... N
SPFEDIT
Work Volser.......
LIBENV... Y
SYSIEWLP
NETMAN... N
REQUIRED
MODHLI............
PDM...... Y
N
Signout on fetch.. Y
PROC..... Y
ELINK XLTE TBL....
Mixed Format...... CCID COMMENT DESCRIPTION
These are the site symbolics defined in your system.
DISPLAY ---------------COMMAND ===>
SYMBOL TABLE: ESYMBOLS
------------ Row 1 to 6 of 6
SCROLL ===> CSR
SYMBOL
VALUE
------------ -----------------------------------------------------------------#ENDEVOR
CA.Software.Endevor
#PERMBASE1
/u/endevor/sampltest/admin/base
Bottom of data
Chapter 8. Using CCIDs
Chapter 8. Using CCIDs 8-1
8.1 Overview
8.1 Overview
Change Control Identifiers (CCIDs) provide Endevor users with an important
project management tool. CCIDs can function as logical grouping mechanisms
by which user-specified portions of the Endevor inventory can be tagged, then
viewed, 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 additional
information. For instance, the person who performs an action might use the
COMMENT field to note the purpose of the action.
Users can specify CCIDs and/or comments when they request actions. You
can decide whether or not to require CCIDs and/or comments for all action
requests on a system-by-system basis.
You can specify a CCID and/or comment when you request any of these
Endevor actions: ADD, UPDATE, RETRIEVE, GENERATE, MOVE,
TRANSFER, DELETE, and RESTORE. Endevor updates the CCID and/or
comment in up to six places with the CCID and/or comment specified in the
action request. Whether a CCID and/or comment is updated depends on the
effect the action has on the source and outputs managed by Endevor.

8.2.1 Six Fields
The six CCID and/or COMMENT fields that may be updated are listed below,
along with an explanation of the information provided by each pair of fields
on the list.
Field
Description
Last Action CCID

and/or comment
The CCID and/or comment used the last time any

action was performed that updated Endevor in any
way (every action except RETRIEVE). This CCID
and/or comment is stored in the Master Control File.
Current Source CCID

and/or comment
The CCID and/or comment used the last time an

Endevor action changed the source. This CCID
and/or comment is stored in the Master Control File.
Generate CCID
and/or comment
The CCID and/or comment used the last time an

Endevor action caused output processing to occur.
Output processing occurs when a processor is run or
an output data set is updated. This CCID and/or
comment is stored in the Master Control File.
Retrieve CCID
and/or comment
These fields only reflect the CCID and/or comment

used during the RETRIEVE action if the last action at
that stage was RETRIEVE. This CCID and/or
comment is stored in the Master Control File.
Viewing this information allows you to determine
which elements have been retrieved for update by a
particular project.
Source Delta CCID

and/or comment
Each delta level contains the CCID and/or comment

specified in the action that created the delta level.
Component List
Delta CCID and/or
comment
Each component list delta level contains the CCID

and/or comment specified in the action that created
the delta level.
8.3 Requiring CCIDs
8.3 Requiring CCIDs

8.3.1 Procedure
During Endevor implementation you should decide whether to require CCIDs
and/or comments.
You can require the use of CCIDs and/or comments on a system-by-system
basis. To require CCIDs and/or comments for a given system:
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 the
ENVIRONMENT field, and press Enter. Endevor displays the System
Definition panel.
UPDATE

NEXT
ENV:
SMPLPROD
SYSTEM:
FINANCE
UPDATED:
GENERAL OPTIONS:
(W/C/E)
(W/C/E)
ACTIVATE OPTION
===> Y (Y/N)
VALIDATE DATA SET
===> N (Y/N)
LIBRARIES:

3. Enter Y in the CCID and/or COMMENT fields, and press Enter to save
your changes.
8.3 Requiring CCIDs
8.3.2 Action Prompt Panel

If you do not specify a CCID and/or comment when one or the other is
required for an action you are requesting, Endevor displays the Action Prompt
panel.
-------------------------------- ACTION PROMPT -------------- COMMENT REQUIRED

COMMAND ===>
Specification Required:
CCID:
Y (Y/N)
COMMENT: Y (Y/N)
Action: GENERATE
Environment: SMPLTEST
Type:
COBOL
CCID
COMMENT
Element: FAPCOB1
System: ADMIN
Stage: TEST
Subsystem: ACCTPAY
===>
===>
To complete your action request, type a valid CCID and/or comment on this
screen and press Enter.
8.4 When Endevor Updates CCID Fields

8.4.1 Overview
You can specify a CCID and/or a comment when requesting Endevor perform
these actions:
ADD
UPDATE
RETRIEVE
GENERATE
MOVE
TRANSFER
DELETE
RESTORE
Endevor uses the CCID and/or comment that you specify for the action to
update 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. The
following sections on specific actions provide details on which of the CCID
and/or COMMENT fields are updated, and under what circumstances. For a
complete description of each action, see the User Guide.
8.4.2 Add Action CCID Updates

When you specify a CCID and/or comment in an ADD action, Endevor
updates CCID and/or COMMENT fields differently depending on whether
you are adding a new element or an existing element.
8.4.2.1 Specifying an Add Action for a New Element

When you specify a CCID and/or comment in an ADD action for a new
element, Endevor uses this CCID and/or comment to:
Set the LAST ACTION CCID and/or COMMENT fields.
Set the CURRENT SOURCE and SOURCE DELTA CCID and/or
COMMENT fields.
Set the GENERATE and COMPONENT LIST DELTA CCID and/or
COMMENT fields if the generate processor is run.
In addition, the first time an element is added to Endevor the comment
specified is stored separately. This comment appears in the ELEMENT
DESCRIPTION field of the Master Control File display, and remains with the
element as long as it resides in Endevor.
8.4.2.2 Specifying an Add Action for an Existing Element

When you specify a CCID and/or comment in an ADD action for an existing
element, Endevor uses this CCID and/or comment to:
COMMENT fields if the element has changed.
Set the generate CCID and/or COMMENT fields if the generate processor
is run.
Set the COMPONENT LIST DELTA CCID and/or COMMENT fields if the
component list has changed.
Endevor also clears the Stage 1 RETRIEVE CCID and/or COMMENT fields
when you add an existing element.
CAUTION:
If you specify the BYPASS GENERATE PROCESSOR option, the ADD
action will not set the generate or component list delta CCID and/or
COMMENT fields.
8.4.3 Update Action CCID Updates

When you specify a CCID and/or comment in an UPDATE action for an
existing element, Endevor uses this CCID and/or comment to:
COMMENT fields if the element has changed.
Set the GENERATE CCID and/or COMMENT fields if the generate
processor is run.
Set the COMPONENT LIST DELTA CCID and/or COMMENT fields if the
component list has changed.
Endevor also clears the Stage 1 RETRIEVE CCID and/or COMMENT fields
when you UPDATE an element.
CAUTION:
If you specify the BYPASS GENERATE PROCESSOR option, the UPDATE
COMMENT fields.
8.4.4 Retrieve Action CCID Updates

When you specify a CCID and/or comment in a RETRIEVE action for an
existing element, Endevor uses this CCID and/or comment to set the
RETRIEVE CCID and/or COMMENT fields.
8.4.5 Generate Action CCID Updates

When you specify a CCID and/or comment in a GENERATE action, Endevor
you specify the GENERATE action with or without copyback.
8.4.5.1 Specifying a Generate Action without Copyback

When you specify a CCID and/or comment in a GENERATE action without
copyback, Endevor uses this CCID and/or comment to:
Set the GENERATE CCID and/or COMMENT fields.
Set the COMPONENT LIST DELTA CCID and/or COMMENT fields if
running the generate processor causes the component list to change.
8.4.5.2 Specifying a Generate Action with Copyback

When you specify a CCID and/or comment in a GENERATE action with
copyback, Endevor uses this CCID and/or comment to:
Set the LAST ACTION CCID and/or COMMENT fields at the generate
location.
COMMENT fields at the generate location.
Endevor also sets current source and source delta CCID and/or COMMENT
fields to the value associated with the element that is copied back.
8.4.6 Move Action CCID Updates

When you specify a CCID and/or comment in a MOVE action, Endevor
you specify the MOVE action with history or without history.
8.4.6.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 CCID
and/or COMMENT fields. Endevor also:
Sets the target CURRENT SOURCE and GENERATE CCID and/or
COMMENT fields to their value at the starting location of the MOVE.
Sets the target SOURCE DELTA and COMPONENT LIST DELTA CCID
and/or COMMENT fields to their last value at the starting location of the
MOVE.
Clears the RETRIEVE CCID and/or COMMENT fields.
8.4.6.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 CCID
and/or COMMENT fields. Endevor also:
Sets the CURRENT SOURCE and GENERATE CCID and/or COMMENT
fields to their start location value.
Moves SOURCE DELTA and COMPONENT LIST DELTA CCIDs and
COMMENTs with their respective delta levels.
8.4.7 Transfer Action CCID Updates

When you specify a CCID and/or comment in a TRANSFER action, Endevor
you specify the TRANSFER request without history, with history, or with
synchronization.
8.4.7.1 Specifying a Transfer Action without History

When you specify a CCID and/or comment in a TRANSFER action without
history, Endevor uses this CCID and/or comment to:
Endevor also:
Sets the CURRENT SOURCE CCID and/or COMMENT fields from their
value in the previous stage.
Sets the SOURCE DELTA CCID and/or COMMENT fields from their last
delta value in the previous stage.
8.4.7.2 Specifying a Transfer Action with History

When you specify a CCID and/or comment in a TRANSFER action with
history, Endevor uses this CCID and/or comment to:
Endevor also:
Sets the CURRENT SOURCE CCID and/or COMMENT fields from their
value in the previous stage.
Moves SOURCE DELTA CCIDs and COMMENTs with their respective
delta levels.
When you specify SYNCHRONIZE along with the TRANSFER WITH
HISTORY option, Endevor creates a synchronize source delta level. When
Endevor creates this synchronize delta level it:
Sets the CCID and/or COMMENT fields from the base value.
Sets the synchronize flag to indicate that this source delta level was created
as a result of the synchronize option.
CAUTION:
If you specify the BYPASS GENERATE PROCESSOR option, the
TRANSFER action will not set the generate or component list delta CCID
and/or COMMENT fields.
8.4.8 Delete Action CCID Updates

If you specify a CCID and/or comment on a DELETE action, that CCID
and/or comment is logged to SMF (if SMF logging is being performed). The
CCID and/or comment is available to Endevor exits.
8.4.9 Restore Action CCID Updates

When you specify a CCID and/or comment in a RESTORE action for an
existing element, Endevor uses this CCID and/or comment to:
Endevor sets the CURRENT SOURCE, SOURCE DELTA, and RETRIEVE CCID
and/or COMMENT fields based on the contents of the archive data set from
which you restore.
CAUTION:
If you specify the BYPASS GENERATE PROCESSOR option, the RESTORE
COMMENT fields.
8.4.10 Summary CCID Impact Chart

The chart shown below summarizes the impact of Endevor actions on the six
fields that each action may update with the CCID and/or comment
information that you specify for the action.
Action
Current
Source
CCID/
Comment
Generate
CCID/
Comment
Last
Retrieve Source Delta
Action
CCID/
CCID/ Comment
CCID/
Comment
Comment
Component CCID/
Comment
Add (new
element)
Set
Set if
changed
Set
Set
Set if generated
Add
(existing
element)
Set if
changed
Set if
generated
Set
Set
Set if generate
creates a delta
Update
Set if
changed
Set if
generated
Set
Set if changed
Set if generate
creates a delta
Retrieve
Set
Generate
without
copyback
Generate
with
copyback
Set to
copied
back
value
Signin
Set
Set
Set
Set
Set if generate
creates a delta
Set to copied
back value
Clear
Set
Action
Current
Source
CCID/
Comment
Generate
CCID/
Comment
Last
Retrieve Source Delta
Action
CCID/
CCID/ Comment
CCID/
Comment
Comment
Component CCID/
Comment
Set from
Archive
Set if
generated
Set
Set
from
Archive
Set from Archive
Set if generated
Move
without
history
Set from
start
location
value
Set from
start
location
value
Set
Clear
Set from last start

location delta
value
Set from last start

location delta value
Move
with
history
Set from
start
location
value
Set from
start
location
value
Set
Clear
Carried with
delta levels
Carried with delta

levels
Transfer
without
history
Set from
previous
stage
value
Set if
generated
Set
Clear
Set from last

delta value
previous stage
Set if generated
Transfer
with
history
Set from
previous
stage
value
Set if
generated
Set
Clear
Carried with
delta levels
Set if generated
Transfer
with
SYNC
Set from
previous
stage
value
Set if
generated
Set
Clear
Set from base

value. Carried
with delta levels
+ on SYNC level
Set if generated
Delete
Restore
Archive
8.5 Predefining CCIDs

8.5.1 Overview
Predefining CCIDs allows you to:
Validate CCIDs entered by users against the predefined CCIDs.
Associate user IDs or specific inventory areas with certain CCIDs.
You can predefine CCIDs in several ways. You can:
Define a CCID definition data set within Endevor.
Use a product such as IBM's Information/Management Facility; Endevor
provides an interface for this product.
Create your own file; Endevor provides a user exit capability so you can
define your own CCID definition file.
This section contains information about CCID validation in Endevor and about
the CCID definition data set that you can define within Endevor.
8.5.2 CCID Validation

If you have predefined CCIDs, the CCID definition file is read into memory at
Endevor start-up. Any changes made to the definition file during an Endevor
work session will not take effect until you exit Endevor and then re-enter the
system.
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 construction
screens), but denied at execution time.
CCID validation occurs only if a CCID is specified. If the system you are
working with has not been defined with CCID required and you do not
specify a CCID, CCID (and project) validation is bypassed. If you specify a
CCID for an action (whether or not it is required by the system), CCID
validation is performed.
CCID validation applies only to specific actions. This processing is not
applicable with the LIST or PRINT actions, as you cannot specify a CCID for
these actions.
Note: CCID validation performed by Endevor can be used as a secondary
validation mechanism that is invoked if a no match condition is found in the
Endevor Information/Management Interface. See the Interface for IBM Tivoli
Information Management Administration Guide for more information.
8.5.3 Endevor CCID Definition Data Set

You can define and maintain CCIDs in a sequential file that you identify in the
Defaults Table. This file is optional. It allows you to predefine CCIDs and
associate each CCID, if you choose, with user IDs and/or Endevor inventory
areas.
When a CCID is specified in an Endevor action, Endevor validates that CCID
against the contents of this data set. It determines whether or not the user is
authorized to use the specified CCID in conjunction with the inventory area
against which the action is being performed.
You must maintain the definition file using either the ISPF (or any other) text
editor or by creating the file from your existing project management system.
The definition file must be a card-image data set (80-byte, fixed-format
records).
The format of the records in the CCID definition file is variable; the records
may be comments ("comment lines") or definitions ("definition lines"). CCIDs
are required on every definition line; optionally, a TSO user and/or Endevor
element identification information (environment, system, subsystem, element
name, type, and stage) can be given.
8.5.3.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 in
the format: project.dataset.type
where type is a unique value. This causes the ISPF editor to use a unique
profile 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 the
iprfx.iqual.JCLLIB library into the allocated data set.
SAMPCIPO is a sample CCID definition data set that is distributed with
the Endevor system. You can use SAMPCIPO to build a data set
appropriate to the needs of your organization
For details, see the Getting Started guide.
8.5.3.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 for
editing.
A sequential data set allows you to off-load project management
information from an existing application (such as IBM's
Information/Management system) and construct the data set using an
application program.
Note: To assist in the building of the application program, an assembler
macro has been supplied with the system. The macro can be found in the
installation source library (iprfx.iqual.SOURCE) built during Step 1 of the
Endevor installation process (see the Getting Started guide for details). The
member name of the macro is $CIPOREC.
If you want to write a program to create a CCID definition data set, use the
record layout specified in $CIPOREC, using your own data.
8.5.3.3 Editing the File Using the ISPF Text Editor

Setting up a CCID definition file as a sequential file allows you to use the ISPF
text 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:

*
16
*
25
**
34 36
*
45
*
54
63
8.5.4 Using the CCID Definition Data Set

The CCID definition data set can be used:
To register the names of CCIDs. The CCID definition data set can also
contain user and/or element identification data.
As a secondary or backup CCID validation mechanism, in conjunction
with the Information/Management interface.
If a CCID gets a "no match" condition from the Information/Management
interface, Endevor uses the CCID definition data set to check further. If
the interface recognizes the CCID, then Endevor bypasses the CCID check.
Using the CCID definition feature with this additional information can assist
you in project management. You can create multiple lines in the CCID
definition data set for each valid CCID. For a given CCID value, these
successive lines specify either the users allowed to work under this CCID, the
inventory items/areas which may be worked on, or both.
For example, assume that a site has two projects: TAX-CHNG-89 and
NEW-COMPPLAN. Only people in the Development Department (TSO user
IDs: DEVxxx) are allowed to perform changes as part of these projects. The
inventory 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
CCID
TAX-CHNG-89
TAX-CHNG-89
NEW-COMPPLAN
NEW-COMPPLAN
16
USERID
DEV
DEV
DEV
DEV
25
34 36
45
ENVIRON # SYSTEM
SUBSYS
DEMO
1 PAYROLL
DEMO
1 ACCOUNTG
DEMO
1 PAYROLL
DEMO
1 PERSONEL
54
63
TYPE ELEMENT
8.5.4.1 Sample CCID Definition Data Set

A sample CCID definition data set is provided below.
card
position
3
CCID
AC-DEV-89/2
MA-DEV-89/2
PE-DEV-89/2
PE-DEV-89/2
PE-DEV-89/2
QA-89/2
EMERGNCY-FIX
16
USERID
ZSXBAP1
ZSX
ZSXJMH1
ZSXPGM1
ZSXSXV1
ZSXREL1
25
34 36
45
ENVIRON # SYSTEM
SUBSYS
DEMO
1 ACCOUNTG
DEMO
1 MANUFACT
DEMO
1 PERSONEL
DEMO
1 PERSONEL
DEMO
1 PERSONEL
DEMO
2

2
54
63
TYPE ELEMENT
Certain coding conventions apply to this data set:

Any line that begins with an asterisk (*) in column 1 is considered a
comment line.
Every non-comment line is considered a definition line, and must specify a
CCID. 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 sample
above), it is ignored.
Name masks (for example, ZSX* or simply * in the sample above) can be
used in any of the optional fields. Imbedded asterisks are not allowed.
A description of each field in the data set follows.
Field
Card
Position
Description
CCID
The name of the CCID. The name must be

fully specified, defining a valid CCID. This
value must be specified on every definition
line. The same CCID may appear on
multiple lines.
Userid 1
16
If used, only the users whose user ID is

specified (whether by full name or with the
use of a name mask) may use the CCID
indicated on this line.
Environ 1
25
Environment name. If used, only elements

in the environment specified (whether by
full name or with the use of a name mask)
can be updated under the CCID indicated
on this line.
# 1
34
Stage number. If used, only elements in

the stage specified (either 1, 2, or *) can be
updated under the CCID indicated on this
line.
System 1
36
System name. If used, only elements in the

system specified (whether by full name or
with the use of a name mask) can be
line.
Subsys 1
45
Subsystem name. If used, only elements in

the subsystem specified (whether by full
name or with the use of a name mask) can
be updated under the CCID indicated on
this line.
Type 1
54
Element type. If used, only elements of the

type specified (whether by full name or
with the use of a name mask) can be
line.
Field
Card
Position
Description
Element 1
63
Element name. If used, only elements

whose names are specified (whether by full
name or with the use of a name mask) can
be updated under the CCID indicated on
this line.
Note:
1: These fields are optional.
Chapter 9. SMF Recording

If the SMF interface is implemented at your site (as described in the Getting
Started 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 an
SMF Security Record.
For each action executed, Endevor can write out an appropriate SMF
Action Record at the end of action processing. Exceptions are the SIGNIN,
PRINT, DISPLAY, COPY, and LIST actions, for which SMF recording does
not apply.
Endevor writes out SMF records if requested during installation, through the
Defaults Table. It writes Security Records if the Defaults Table specifies
SMFSEC=Y, and it writes Action Records if the Defaults Table specifies
SMFACT=Y. (A third Defaults Table option, SMFENV, is not supported with
this release of the software.) SMF records are specific to an environment. For
example, you might request SMF records for one environment but not another.
For details about the Defaults Table, see the Getting Started.
Notes:
Within this chapter, any discussion of SMF Security Records assumes you
are working with the native security facility. If the optional External
Security Interface (Endevor ESI) is installed at your site, see the Security
Guide for related information.
Any of your pre-release 4.0 programs that read the SMF records created by
Endevor may need some source changes, but must at least be reassembled
and 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

9.1.1 Overview
Endevor uses several blocks to build the SMF Security and Action Records,
each comprising one or more DSECTs. All DSECTs are supplied in
iprfx.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 the
environment and user names for the element being processed. Endevor
records can be identified by the record type field in the header block
(SMHRECTY), which is defined in the Defaults Table for each site (230 by
default). This field is the same for each Endevor SMF record, and identifies
the records as being specific to Endevor.
Following the header block, each record has a data block that is specific to the
record type:
DSECT $SMFREC1 for Security Records
DSECT $SMFREC2 for Action Records
For Action Records, the $SMFREC2 block encompasses one or more
action-specific blocks, as described further below. For a detailed description of
each DSECT used to format SMF records, see 9.2, DSECT Descriptions on
page 9-5.
9.1.2 SMF Security Records

SMF Security Records include data specific to the security violation being
reported. The data block for Security Records is written out using DSECT
$SMFREC1. The combined format for SMF Security Records, then, is described
using the following DSECTs:
$SMFHDDS
$SMFREC1
9.1 Record Formats
9.1.3 SMF Action Records

SMF Action Records include data specific to the action being reported, and
apply for all actions except PRINT, DISPLAY, COPY, and LIST. Each Action
Record has one occurrence of the $SMFREC2 DSECT, and one or more
action-specific blocks from the $SMFBKDS DSECT, as appropriate to the
action. 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 further below and identified separately in 9.2.5, $SMFBKDS DSECT:
Action-Specific Blocks on page 9-13.
The combined format for SMF Action Records, then, is described using the
following 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 a
different format, or DSECT (within the $SMFBKDS DSECT). Each format
applies to specific actions, as described briefly below. Where two occurrences
of a DSECT are used by an action, "(2)" follows the action name, below.
Action
Block
Detail
Type #
DSECT
Type
Actions
Description
Environment
(SM2ENVDS)
Add (2)
Update (2)
Retrieve (2)
Generate
Move(2)
Delete
Transfer (2)
Archive (2)
Restore (2)
Information describing the

environment where the action
took place: name of the
environment, site ID, etc.
Where two blocks are used, one
represents the source
environment for the element,
while the other represents the
target environment.
Last Change
(SM2LCGDS)
Add
Update
Generate
Move
Delete
Transfer
Restore
Information describing the last

action (the action being
recorded): date and time of the
action, comments describing the
action, and so forth.
Processor
Info
(SM2LPRDS)
Add
Update
Generate
Move
Delete
Transfer
Restore
Information about the last

processor executed: processor
name, date and time of
execution, etc. Used for actions
that can invoke a processor.
Request
Parameter
Info
(SM2REQDS)
All actions
General information about the

action: CCID, comments, and so
forth.
9.2 DSECT Descriptions

9.2.1 Overview
This section describes each of the DSECTs used to write out SMF Action and
Security Records. In cases where specific fields are not applicable for the
current processing, alphabetic fields are space-filled and numeric fields are
zero-filled.
9.2.2 $SMFHDDS DSECT: SMF Header Block

The header block is written at the beginning of each SMF record. Endevor
Security and Action Records can be identified by the record type field in the
header, 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$RF1 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
SMHSIZE
SMHDATA
DS
EQU
EQU
MEND
D
-$SMFHDDS
SIZE OF THE HEADER ( FOR SMHHDLEN)

START OF THE DATA
9.2.2.1 SMF Header Block Field Descriptions

Field
Description
SMHLEN
Size of the (Security or Action) record, in bytes. This

includes the size of the header block as well as the
data block:
$SMFREC1 Security Records
$SMFREC2 (including all action-specific blocks)
Action Records
SMHSEGID
Not used.
SMHSID
Operating system against which the SMF record is

written. Always X'02' with release 3.7.
SMHRECTY
Number that identifies this SMF record as specific to

Endevor. This number is defined to Endevor through
the Defaults Table.
SMHTIME
Time the SMF record was created (binary time of day

in 100ths of a second 1 = .01 second).
SMHDATE
Date the SMF record was created (packed yyddd).
SMHCPUID
Number to identify the CPU model on which

Endevor is running.
SMHHDLEN
Size of the header block (DSECT $SMFHDDS), in

bytes.
SMHC1VER
Code that identifies the format of the SMF record.

SMH$RF00 This record was created by
Endevor release 2.2 or a prior release.
SMH$RF01 This record was created by
Endevor release 2.5 or a later release.
SMHCTLTY
Code that identifies the next record format in the

SMF record.
SMHCONT
Not used.
SMHSEQ
Not used.
SMHC1ENV
Environment name associated with the current

processing.
SMHUSER
User ID associated with the current processing.
SMHSIZE
Size of the $SMFHDDS DSECT.
9.2.3 $SMFREC1 DSECT: Security Record Data Block

This DSECT applies for Security Records, and includes data specific to the
security 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$V2
EQU
X'2'
VERSION 2
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(13)
AREA BUFFER SPACE.

DS
D
SM1SIZ
EQU
-$SMFREC1
SIZE OF THE RECORD
MEND
9.2.3.1 Security Record Data Block Field Descriptions

Field
Description
SM1RECLN
Size of this data block (DSECT $SMFREC1), in bytes.
SM1RECVN
Version number. Identifies the Endevor release that

created 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: generally

the type of action. For specific values that apply
here, see the definition of field ECBFUNC in the
Getting Started guide.
SM1FUNNM
Applicable if SM1FUNC references an Endevor

action. Name of the current action (ADD, UPDATE,
etc.).
SM1ERRCD
The 4 characters that are used to construct the error

code written to the Endevor Execution Report for the
current action in the ECBMSGCD field, as described
in 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, as

described 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

action. Stage ID for the current action request.
SM1IFUNC
Action information that is used internally by

Endevor. For the specific values that apply here, see
the definition of field ECBIFUNC, in the Getting
Started guide.
SM1ENVM
Environment name for the current processing.
SM1STAGE

action. Stage name for the current action request.
SM1SYSTM

action. System name for the current action.
SM1SUBSY

action. Subsystem name for the current action.
SM1STYPE

action. Element type for the current action.
SM1ELEMT 1

action. Name of the element specified for the current
action. row.
SM1EAOFF 2
Element area offset. When the offset is added to the

beginning of the record's address, the resulting
address points to an area with in the SM1BFAREA.
The element area is comprised of two adjacent
components:
Two byte field containing the length
Element name
SM1DSNAM 1
Applicable for security violations that relate to ADD,

UPDATE, RESTORE, ARCHIVE, and RETRIEVE
action requests. Data set name associated with the
external file used by the current action.
Field
Description
SM1FAOFF 2
File area offset. When the offset is added to the

The file area is comprised of two adjacent
components:
File name
The file name may be a traditional file or an HFS
path name.
SM1DSMEM 1
Applicable for security violations that relate to ADD,

UPDATE, RESTORE, ARCHIVE, and RETRIEVE
action requests. Member name associated with the
element for which the current action applies, within
the above data set. Applicable when the data set is a
library.
SM1NAOFF 2
Name area offset. When the offset is added to the

The name area consists of two adjacent components:
File name
The name may be a member name or an HFS file
name.
SM1BSIZ
Base size of the record.
SM1BFAREA 2
This is reserved record space containing the various

areas 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.4 $SMFREC2 DSECT: Action Record Data Block

This DSECT applies for Action Records, and includes information specific to
the action being reported. Depending on the action type, one or more
action-specific blocks (pairs of DSECTs) are incorporated at the end of this
DSECT. For more information, see the discussion of 9.2.5, $SMFBKDS
DSECT: Action-Specific Blocks on page 9-13.
$SMFREC2
$SMFREC2 DSECT
$SMFREC2 DS
D
ALIGN IT

$SMFREC2 - DESCRIPTION FOR THE ACTIVITY RECORD

SM2REC1 EQU

SM2RECLN DS
H
LENGTH OF THE ACTIVITY RECORD
SM2RECVN DS
H
SM2$V1
EQU
X'1'
VERSION 1
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
1CL1
EXTRA ROOM
SM2SIZ
EQU
-$SMFREC2
SIZE OF THE RECORD
MEND
9.2.4.1 Action Record Data Block Field Descriptions

Field
Description
SM2RECLN
Size of this data block (DSECT $SMFREC2), in bytes,

including all action-specific blocks included at the
end (DSECT $SMFBKDS).
SM2RECVN
Version number to identify this data block

($SMFREC2). This should always be 1. Use the
SM2$VERS label to verify that the correct version of
this DSECT was used:
For example, a value of one with the label SM2$VERS
means the version for that block is 1.
SM2FUNC
Number that identifies the current activity: generally

the current type of action. For specific values that
apply here, see the definition of field ECBFUNC, in
the Getting Started guide.
SM2FUNNM

action. Name of the current action (ADD, UPDATE,
etc.).
SM2BLKS
Count of action-specific blocks included at the end of

this 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 by

Endevor. For the specific values that apply here, see
the definition of field ECBIFUNC, in the Getting
Started guide.
SM2HDRLN
Size of the $SMFREC2 DSECT, excluding the

action-specific blocks
SM2SIZ
Size of the $SMFREC2 DSECT, including all

action-specific blocks incorporated at the end.
9.2.5 $SMFBKDS DSECT: Action-Specific Blocks

This DSECT applies for Action Records, and includes data specific to the action
being reported. $SMFBKDS includes five DSECTs one action-block header
and four action-block detail DSECTs. These DSECTs are used in pairs, with
each pair including a header and one type 1, 2, 3, or 4 detail DSECT. The type
of detailed information included can be identified through the SM2BTYP field
in 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
DS
H
LENGTH OF THE BLOCK
DS
H
TYPE OF BLOCK
DS
H
VERSION OF BLOCK (SM2B$V1/V2)
DS
CL1
FLAG 1 FOR BLOCK
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
DS
CL1
RESERVED
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(13)
AREA BUFFER SPACE
SM2EDATA DS
D
SM2ENVLN EQU
-SM2ENVDS
LENGTH OF ENV BLOCK

LAST CHANGE BLOCK TYPE 2

AIF
SM2LCGDS DSECT
AGO
.START2
.NODSCT2 ANOP
SM2LCGDS DS
D
ALIGN IT
.START2 ANOP
DS
D
START OF HEADER
SM2LLEN DS
H
LENGTH OF THE BLOCK
SM2ELEN
SM2ETYP
SM2EVER
SM2EFLG1
SM2EFLG2
SM2LTYP
SM2LVER
SM2LFLG1
SM2LFLG2
DS
H
TYPE OF BLOCK
DS
H
VERSION OF BLOCK (SM2B$V1)
DS
CL1
FLAG 1 FOR BLOCK
DS
CL1
FLAG 2 FOR BLOCK
DS
D
END OF HEADER
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
DS
CL2
RESERVED
SM2MLTOT DS
F
LAST LEVEL TOTAL
SM2LDATA DS
D
SM2LCHLN EQU
-SM2LCGDS
LENGTH OF LAST CHANGE BLOCK

PROCESSOR INFO BLOCK TYPE 3

AIF
SM2LPRDS DSECT
AGO
.START3
.NODSCT3 ANOP
SM2LPRDS DS
D
ALIGN IT
.START3 ANOP
DS
D
START OF HEADER
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
DS
D
END OF HEADER
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

AIF
SM2REQDS DSECT
AGO
.START4
.NODSCT4 ANOP
SM2REQDS DS
D
ALIGN IT
.START4 ANOP
DS
D
START OF HEADER
SM2RLEN DS
H
LENGTH OF THE BLOCK
SM2RTYP
SM2RVER
SM2R2
SM2R35
SM2CREL
SM2RFLG1
SM2RFLG2
DS
DS
EQU
EQU
EQU
DS
DS
DS
DC
DC
DC
DC
DC
DC
DC
DC
DC
H
H

1
1
CL1
CL1
D
CL12' '
CL4' '
F''
CL1' '
CL1' '
CL1' '
CL1' '
F''
CL1' '
SM2RCCID
SM2RCOMM
SM2RFLAG
SM2RSISO
SM2RSICO
SM2REXPN
SM2ROVER
SM2RRTCD
SM2RDEL

SM2RIGNF DC
CL1' '
SM2RBGNP DC
CL1' '
SM2RBDLP DC
CL1' '
SM2RSYNC DC
CL1' '
SM2RONCP DC
CL1' '
SM2RMVWH DC
CL1' '
SM2RAWUP DC
CL1' '
SM2RPGRP DC
CL8' '
SM2RSIUS DC
CL8' '
SM2RDATA DS
D
SM2REQLN EQU
-SM2REQDS
MEND
TYPE OF BLOCK
VERSION OF BLOCK
RELEASE 2.2 FORMAT THRU RELEASE 3.
RELEASE 3.5 FORMAT
CURRENT RECORD FORMAT VERSION
FLAG 1 FOR BLOCK
FLAG 2 FOR BLOCK
END OF HEADER
CCID ASSOC W/ ACTION
COMMENT ASSOC W/ ACTION
ANY SPECIAL FLAGS
SIGNIN/SIGNOUT FORCE ( Y OR N)
SIGNIN/SIGNOUT COPY ONLY ( Y OR N)
EXPAND INCLUDES ( Y OR N)
WRITE OVER EXISTING RETR MBR
ACTION RETURN CODE
DELETE REQUEST FLAG
BLANK IF N/A
Y - YES, DELETE WAS REQUESTED
N - NO, DELETE WAS NOT REQUESTED
IGNORE GENERATE FAILED
(Y / N)
BYPASS GENERATE PROCESSOR (Y / N)
BYPASS DELETE PROCESSOR
(Y / N)
SYNC OPTION SPECIFIED
(Y / N)
DELETE ONLY COMPONENTS
(Y / N)
MOVE/TRANSFER W/ HISTORY (Y / N)
ADD W/ UPDATE OPTION
(Y / N)
PROCESSOUR GROUP OVERRIDE
SIGNOUT TO USERID
LENGTH OF PROCESS BLOCK
9.2.5.1 Action-Block Header Field Descriptions (SM2BHDDS)

Field
Description
SM2BLEN
Size of this action-specific block (action-block header,

SM2BHDDS, plus the action-block detail DSECT), in
bytes.
SM2BTYP
Code that indicates the DSECT used to write out the

action-block detail for this action- specific block:
SM2BVER
Version number to identify this DSECT ($SMFBKDS).

This should always be 1 except for the action block
header. A value of two in this block signifies the
block is created using Endevor 4.0.
SM2BFLG1
Not used.
SM2BFLG2
Not used.
Field
Description
SM2BHDR
Size of the action-block header ($SM2BHDDS).
9.2.5.2 Environment Action-Block Detail Field Descriptions (SM2ENVDS)

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 the

element for the action request.
SM2LVL
Number to identify the current level of the element

for 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 action

request.
SM2EAOFF 2
Element area offset. The element name for the

current action request is stored in the buffer area
located near the end of the record. When the offset is
added to the beginning of this record's address, the
resulting address points to an area within
SM2EAREA buffer space. The element area is
composed of two adjacent components:
Two-byte length field
Element name
SM2DSNAM 1
Applicable for ADD, UPDATE, RESTORE, ARCHIVE,

and RETRIEVE action requests. Data set name
associated with the external file used by the current
action.
Field
Description
SM2FAOFF 2
File area offset. The file name for the current action
request is stored in the buffer area located near the
end of the record. When the offset is added to the
beginning of this record's address, the resulting
address points to an area within SM2EAREA buffer
space. The file area is composed of two adjacent
components:
Data set name
The file name may be a traditional data set or an HFS
path name.
SM2DSMEM 1
Applicable for ADD, UPDATE, RESTORE, ARCHIVE,

and RETRIEVE action requests. Member name
associated with the element for which the current
action applies, within the above data set. Applicable
when the data set is a library; blank otherwise.
SM2NAOFF 2
Name area offset. The member name for the current

action request is stored in the buffer area located near
the end of the record. When the offset is added to
the beginning of this record's address, the resulting
address points to an area within SM2EAREA buffer
space. The name area is composed of two adjacent
components:
Member name (PDS file) or file name (HFS)
If a member/file name is not applicable to the current
action, the offset value is set to zero.
SM2EAREA 2
Space reserved in the record containing various data

such as the element, file and member name.
SM2ENVLN
Size of the action-specific block (header and detail) if

the action-block detail uses the Environment DSECT
($SM2ENVDS).
Note:
1: Version 1 record only
2: Version 2 record only
9.2.5.3 Last Change Action-Block Detail Field Descriptions (SM2LCGDS)

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 the

current level.
SM2LCHLN

the action-block detail uses the Last Change DSECT
($SM2LCGDS).
9.2.5.4 Processor Information Action-Block Detail Field Descriptions (SM2LPRDS)

Field
Description
SM2LPRON
(Element) name of the processor last run for the

element.
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

the action-block detail uses the Processor Information
DSECT ($SM2LPRDS).
9.2.5.5 Request Parameter Info Action-Block Detail Field Descriptions

(SM2REQDS)
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 a

signout override: Y or N 1
Field
Description
SM2RSICO
Applicable for a RETRIEVE action. Indicates whether

the current action specified copy-only: Y or N 1
SM2REXPN

the current action requested that INCLUDEs be
expanded: Y or N 1
SM2ROVER

the current action requested an overwrite if a
member by the same name exists already in the
output library: Y or N 1
SM2RRTCD
Not used.
SM2RDEL
Indicates whether the element was deleted upon

completion of the requested action: Y or N 1. This
value is X'40' if a delete does not apply for the
current action.
SM2REQLN

the action-block detail uses the Request Parameter
Information DSECT ($SM2REQDS).
Note:
1:Y Yes; N No
9.2.6 $SMFREC4 DSECT: Environment Record Data Blocks

This DSECT applies for Environment Records, and includes data specific to the
environment being reported.
$SMFREC4
1
2
3
4
5
6
7
8
9
1
11
12
13
14
15
16
MACRO
$SMFREC4
&DSCT=YES
AIF
('&DSCT' NE 'YES').NODSCT
$SMFREC4 DSECT
AGO
.START
.NODSCT
ANOP
$SMFREC4 DS
D
ALIGN IT
.START
ANOP

$SMFREC4 - DESCRIPTION FOR THE ENVIRONMENT RECORD

SM4REC4
EQU

SM4RECLN DS
H
LENGTH OF THE ENVIRONMENT RECORD
&NAME
17
18
19
191
192
193
2
21
22
23
24
25
26
27
28
29
3
31
32
33
34
35
36
37
38
39
4
41
42
43
44
SM4RECVN DS
H
SM4$VERS EQU
X'1'
VERSION 1
SM4FUNC
DS
F
FUNCTION CODE
SM4$FCRE EQU
1
. CREATE NEW RECORD
SM4$FERA EQU
2
. ERASE RECORD
SM4$FUPD EQU
3
. UPDATE EXISTING RECORD

ENVIRONMENT INFORMATION

SM4TYPE
DS
CL3
RECORD TYPE
SM4T$AGR
EQU C'AGR'
- APPROVER GROUP RECORD
SM4T$AGJ
EQU C'AGJ'
- APPROVER GROUP JUNCTION
SM4T$DSR
EQU C'DSR'
- DATA SET RECORD
SM4T$ELE
EQU C'ELE'
- ELEMENT RECORD
SM4T$PGR
EQU C'PGR'
- PROCESSOR GROUP RECORD
SM4T$SBS
EQU C'SBS'
- SUBSYSTEM RECORD
SM4T$SYS
EQU C'SYS'
- SYSTEM RECORD
SM4T$TSQ
EQU C'TSQ'
- TYPE SEQUENCE RECORD
SM4T$TYP
EQU C'TYP'
- TYPE RECORD
SM4SITE
DS
CL1
SITE CODE
SM4ENV
DS
CL8
ENVIRONMENT NAME
SM4STAGE DS
CL8
STAGE NAME
SM4MCF
DS
CL44
MCF FILE DATA SET NAME
DS
D
DS
3H
RESERVED
SM4DLEN
DS
H
LENGTH OF SUBSEQUENT DATA BLOCK
SM4DATA
DS
X
SM4SIZ
EQU
-$SMFREC4
SIZE OF THE RECORD
MEND
Chapter 10. Global Type Sequencing

A type processing sequence is used when multiple element types are processed
within a single batch request. When Global Type Sequencing is enabled,
element actions are processed by type sequence regardless of the inventory
location of each action. SCL and API element actions are executed in type
sequence order defined at the site level in the Type Sequence member created
by the administrator.
By default, AllFusion Endevor allows you to define the relative sequence of
processing for the various element types defined within a system. If your site
does not choose the Global Type Sequencing option, element actions execute
within your system in the same order as the types were defined to the system
and stage by the administrator or as reordered by the administrator using the
Type Sequence panel.
When Global Type Sequencing is in effect, any types that are not included in
the Type Sequence member are processed after all the types in the Type
Sequence member have completed processing.Then they are processed in type
name order.
The system MCF type sequence record is automatically maintained. However,
the administrator cannot re-order the sequence, in foreground using the Type
Sequence 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 the
Type Sequence member has been created and the type's processing sequence is
important, edit the Type Sequence file to include the type in its proper
processing order.
If the Alternate ID features is active, Endevor uses the Alternate ID when
accessing the PARMLIB file. This way the administrator can secure the file to
the Alternate ID.
Under Batch Admin, system level type sequencing is allowed; however, a
warning message is generated when Global Type Sequencing is in effect at
your site.
Chapter 10. Global Type Sequencing 10-1
To implement Global Type Sequencing, the AllFusion Endevor administrator

must:
Allocate the Parmlib data set
Create a Type Sequence member file
Define the Parmlib data set and the Type Sequence member to the Site
Options 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 the
Parmlib data set, edit the BC1JEPRM member in your site's AllFusion Endevor
JCLLIB data set, and then execute the batch job.

The order of the type records in the Type Sequence member represents the
processing sequence. You create and edit this file and then copy it to your
site's Type Sequence member within AllFusion Endevor's Parmlib data set.
Types not defined in the member are processed in type name order after all
types defined in the Type Sequence file are processed. The Type Sequence
member is composed of 80 byte records. You can use the standard ISFP editor
to create the file. A utility is provided to assist you in building the file.
10.2.1 Syntax Rules for Type Records

The 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 named
types to be associated to different systems when different type sequence
orders are needed. If this clause is omitted, the type sequence order for
that type name will apply to the entire site.
The type name may be contained in single quotes, but this is not
necessary.
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 greater
than 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 contains
single quotes, these quotes will be converted to blanks.
The description text may be entered in either upper or lower case
characters.
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 same
lines.
Text must not appear in columns 73 to 80.
You can add comment records to the file, by placing an asterisk in the first
column position.
10.2.2 Sample Type Sequence File

The following is a sample of a type processing sequence file whose member
name is ETYPESEQ. In this example, elements with a type of PROCESS will be
processed 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 Member

The build utility is JCL member BC1JBTSE available in the site's AllFusion
Endevor CM JCLLIB data set. This utility builds type sequence records for all
types defined to a site. Edit this member to conform to the needs of you
installation before executing this job. The JCL builds a type sequence file to a
sequential work file. You will probably need to edit this file by rearranging the
type order or delete types from the file.
The utility extracts all MCF types defined in the site's C1DEFLTS table and as
each unique type name is encountered, a type sequence record is created.
The utility does not merge one system's type sequence with another. Unique
type records are written to the file as they are processed, starting with the first
system in the first defined C1DEFLTS' environment/stage. The type sequence
record's description field contains the description from the first unique type
record.
The utility produces comment records to identify each type location
occurrence. 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
ENV: DEV
SYSTEM: BASE
ENV: QA
SYSTEM: BASE
ENV: QA
SYSTEM: BASE

STG:
STG:
STG:
STG:
1
2
1
2
The description field in the sequence record is set to the type's description
value. In this case, the description value is taken from location: environment
DEV, system BASE, stage 1. The stage values in the comment records are set
to the stage number, not the ID value.
Considerations for Using the Utility: Most sites have favored environments
where their types follow the site's administration policies. For example, your
site could have environment D40 and I40, which have many test systems
where many elements in these locations have never been promoted up. If your
site also had Q40 and P40 environments that represent true production
inventory, it would be best to run the utility against environments Q40 and
P40 only.
To accomplish this, you can create a temporary C1DEFLTS table where the
D40 and I40 environments are removed. Then this table could be used for just
this utility execution run. Doing this could limit the number of generated type
statements, which could help you define the initial type sequence order. Any
valid types from environment D40 and I40 could then be added manually.

The Parmlib data set contains the Type Sequence member. Both the Parmlib
data set and the Type Sequence member must be defined to the Site Options
Table, C1DEFLTS. The C1DEFLTS table will not assemble correctly if the Type
Sequence member is defined to C1DEFLTS, but the Parmlib is not defined. An
empty Type Sequence member will force type sequencing by type name order.
To define the Parmlib data set and the Type Sequence file to Endevor, you
must add the PARMLIB= and TYPESEQMBR= parameters to C1DEFLTS and
then assemble and link-edit it to your authorized library as member
C1DEFLTS. For details, see the Endevor Optional Features Table in the
chapter "Optional Features."
Chapter 11. The User Options Menu Facility
Chapter 11. The User Options Menu Facility 11-1
11.1 Overview
11.1 Overview
11.1.1 Menu Functions
The User Options Menu facility allows the Endevor administrator to attach
user-defined functions to the Endevor ISPF front end. These functions appear
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
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 the

iprfx.iqual.ISPPLIB library. The CLISTs, panels, messages, and skeleton JCL for
the 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 members
C1SR8000 and C1SR8100.
11.2 User Option Menu Panel Overview

The User Option Menu panel is delivered with functionality to invoke a report
CLIST, the ACM Query CLIST. You may decide to modify this panel to
remove selections not installed at your site or to add additional Endevor
related selections for features you develop.
If you decide to customize the User Options Menu, we recommend you do so
within Endevor. This ensures any changes you make are recorded as change
levels.
11.2.1 Source
The source for the User Options Menu, as delivered and installed with
Endevor, is shown below:
)ATTR
/----------------------------------------------------------------/
/
/
/ (C) 22 COMPUTER ASSOCIATES INTERNATIONAL, INC.
/
/
/
/ 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 Menu

To add options on this panel:
1. Add an option character and descriptive text to the )BODY section of the
panel. It is recommended that you copy one of the existing lines as a
starting 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 of
the panel source. For example:
U,'CMD(%NDVRUTL DEBUG(NOBUG))'
To remove options on this panel:
1. Remove the option character and descriptive text from the )BODY section
of the panel. This can be accomplished by typing over the characters
using 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 deleting
the entire line or by making it into a comment by placing the /* before
and after the parameters. For example:
/
3,'CMD(%ENNMENU DEBUG(NOBUG))'
/
ISPF panels support a maximum of 24 display lines. The delivered panel

contains 24 lines. Line 23 contains the text "Enter END to return" and the 24th
line is left blank to support split screen mode. It is strongly recommended that
you do not alter the number of lines in the )BODY section. If the panel
contains more than 24 lines, ISPF issues an error message when attempting to
display the panel. If it contains less than 24 lines, ISPF adds blank lines to the
end 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.
Delete a blank line when adding a new line.
Chapter 12. The ISPF Dialog Options Configuration

Table
This appendix explains how you can customize the Endevor ISPF dialog
options configuration table for your site.
Chapter 12. The ISPF Dialog Options Configuration Table 12-1
12.1 Overview
12.1 Overview
12.1.1 What Is This Feature?
The dialog options configuration table feature allows you to override default
values set for specific options associated with Endevor actions. The defaults are
assigned in an ISPF dialog configuration table that is shipped with the
Endevor installation files. You can override the assigned default values by
updating and assembling the ISPF configuration table, ENDICNFG.
If you do not want to change the dialog default field values, you do not need
to take any action. Endevor uses the configuration table that is shipped with
the installation tape.
Important! This feature allows you to establish the default values that appear
automatically on the foreground action panels. During an Endevor session, however, a
user can still change the value for one or more options on an individual panel(s).
12.1.2 What You Can Change

You can set default values for all Y/N action option fields and for most list
fields. You can also set the default package selection fields. See the table in
Dialog Options Fields for a list of the dialog fields that can be updated.
12.1.3 What You Cannot Change

You cannot set default values for the CCID, COMMENT, PROCESSOR GROUP
fields, the list option WHERE fields, or data set name fields.
12.2 The Default Configuration Table

12.2.1 Overview
The Endevor files contain the default configuration table, ENDICNFG, and the
JCL you can use to reassemble and link-edit the table. This table contains the
existing default values.
To change the default of any dialog field, proceed as follows:
Step
Action
Edit the parameters you want to change.
Reassemble and link-edit the configuration table.
The default configuration table is shown on the next page. The JCL you use to
reassemble and link-edit the table is shown in the section JCL (BC1JCNFG).
The parameters are discussed in the section Dialog Options Fields.
The table shown below is the default configuration table provided with the
Endevor installation files as a member in the installation SOURCE library.
Note: The default configuration table is regularly updated until the time of
shipping. For the most recent version of ENDICNFG, refer to the member
ENDICNFG 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,
BUILD_USING_MAP=Y,
COMMITTED=Y,
COMPONENT_LIST_WORD=LIST,
COMPONENTS_ONLY=N,
COPYBACK=N,
DELETE_AFTER_ARCHIVE=N,
DELETE_AFTER_MOVE=Y,
DELETE_AFTER_TRANSFER=Y,
DELETE_INPUT_SOURCE=N,
DELETE_MODE=F,
DENIED=Y,
DISPLAY_PROC_GROUP=N,
ENABLE_BACKOUT=Y,
ENTERPRISE_PKG=A
EXECUTED=Y,
EXPAND_INCLUDES=N,
GENERATE_ELEMENT=Y,
GENERATE_MODE=F,
IN_APPROVAL=Y,
IN_EDIT=Y,
IN_EXECUTION=Y,
INCLUDE_JCL=N,
INCREMENT_JOBNAME=Y,
INTERCEPT_ISPF_RETURN=N,
JCL_PROCEDURE_NAME=ENDEVOR,
MOVE_MODE=F,
MULTIPLE_JOBSTREAMS=N,
OVERRIDE_SIGNOUT=N,
PROCESSOR_GROUP_DEFAULT_CHAR=-,
PROCESSOR_GROUP_OVERRIDE_CHAR=O,
QE_BUILD_USING_MAP=Y,
QE_GENERATE_IN_PLACE=N,
QE_RETURN_FIRST_FOUND=Y
REPLACE_MEMBER=N,
RETAIN_SIGNOUT=N,
RETURN_FIRST_FOUND=Y,
SHARABLE_PACKAGE=N,
SHOW_TEXT=Y,
SIGNIN_MODE=F,
SIGNOUT_ELEMENT=Y,
SIGNOUT_MODE=F,
SORT_BY_DESTINATION_ID=2,
SORT_BY_PACKAGE_ID=3,
SORT_BY_SHIP_DATE=1,
SYNCHRONIZE=N,
UPDATE_IF_PRESENT=N,
VALIDATE_COMPONENTS=Y,
WITH_HISTORY=N,
WORKLIST_PRIMARY=1
WORKLIST_SECONDARY=1
END
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
12.3 Dialog Options Fields

Each option is a dialog field in the configuration table. There are two kinds of
fields: those that affect how Endevor processes the action and those that affect
the information returned or presented by Endevor.
The table below lists each of the Endevor dialog fields for which your site can
override the default value. The first column contains the field names as they
appear in the configuration table. These names map to the action option or list
option names that appear on the element or package action panels. The last
column in the table indicates whether this is an action option (A), a list or filter
option (F), or an option that influences Endevor's behavior (O).
ISPF Dialog
Field Name
Valid
Values
Current
Default
Panel Field
Description
Action,
Filter, or
Other
ACKNOWLEDGE_Y or N
ELEMENT_JUMP
Acknowledge
element jump.
APPEND_SCL
Y or N
Default value for

the APPEND
field on the Batch
Options panel.
APPEND_SCL_
PKG
Y or N
Default value for

the APPEND TO
PACKAGE field
on the
Create/Modify
Package panel.
APPROVED
Y or N
Include
APPROVED
packages.
BUILD_USING_
MAP
Y or N
Build the element

selection list using
the Environment
Map.
COMMITTED
Y or N
Include
COMMITTED
packages.
COMPONENT_
LIST_WORD
User-defined
LIST
Text string used to

identify the listing
data set name
when the LL
option is selected
in Quick-Edit.
ISPF Dialog
Field Name
Current
Default
Panel Field
Description
Action,
Filter, or
Other
COMPONENTS_ Y or N
ONLY
Delete only the

element
Component List.
COPYBACK
Y or N
Copy an element
from up the map
during generate
processing.
DELETE_
AFTER_
ARCHIVE
Y or N
Delete the element

or package after
the ARCHIVE
action completes.
DELETE_
AFTER_
MOVE
Y or N
Delete the source

element after the
MOVE action
completes.
DELETE_
AFTER_
TRANSFER
Y or N
Delete the source

element after a
TRANSFER action
completes.
DELETE_
INPUT_
SOURCE
Y or N
Delete the input

source after an
ADD action
completes.
DELETE_
MODE
F or B
Default mode
when executing
the delete action
in Quick-Edit; F
for foreground, B
for batch.
DENIED
Y or N
Include denied
packages.
DISPLAY_
PROC_GROUP
Y or N
Default value for

F
the DISPLAY
PROC GRP
NAME field on
the Display
Elements/Component
Lists panel.
ENABLE_
BACKOUT
Y or N
Enable package
backout.
Valid
Values
ISPF Dialog
Field Name
Valid
Values
Current
Default
Panel Field
Description
Action,
Filter, or
Other
ENTERPRISE_
PKG
A or E or X
ISPF Package
Selection list filter
option. If A, lists
enterprise and
non-enterprise
packages. If E,
lists enterprise
packages only.If
X, lists
non-enterprise
packages only.
EXECUTED
Y or N
Include executed
packages
EXPAND_
INCLUDES
Y or N
Expand imbedded
INCLUDES
during a
RETRIEVE action.
GENERATE_
ELEMENT
Y or N
Generate an
element as part of
quick-edit or
transfer
processing.
GENERATE_
MODE
F or B
Generate the
element in
Foreground (F) or
Batch (B) in
Quick-Edit.
IN_APPROVAL
Y or N
Include packages
that are in the
approval process.
IN_EDIT
Y or N
Include packages
that have not yet
been cast.
IN_EXECUTION Y or N
Include packages
that are executing.
INCLUDE_JCL
Default value for

the INCLUDE
JCL field on the
Batch Options
panel.
Y or N
ISPF Dialog
Field Name
Valid
Values
Current
Default
Panel Field
Description
Action,
Filter, or
Other
INCREMENT_
JOBNAME
Y or N
Indicates whether
the Batch Package
Facility increments
the last character
in the jobcard you
provide when you
submit a package
jobstream.
INTERCEPT_
ISPF_RETURN
Y or N
Instruct Endevor
whether to
intercept ISPF
RETURN and
JUMP commands.
JCL_
PROCEDURE_
NAME
1-8
alphanumeric
characters
Endevor
The name of the

Endevor
procedure that the
SUBMIT
PACKAGE action
will use to create
JCL. A sample
procedure can be
found in
iprfx.iqual.
JCLLIB, member
name PACKAGE.
Use this as a
model for your
own Submit
procedure.
MOVE_MODE
F or B
Default mode
when executing
the move action in
Quick-Edit; F for
foreground, B for
Batch.
ISPF Dialog
Field Name
Valid
Values
Current
Default
Panel Field
Description
Action,
Filter, or
Other
MULTIPLE_
JOBSTREAMS
Y or N
Indicates whether
multiple packages
are submitted as
separate jobs (Y)
or as job steps
within a single
jobstream (N),
when using the
Batch Package
Facility
(ENBP1000).
OVERRIDE_
SIGNOUT
Y or N
Override the
element signout
status.
PROCESSOR_
GROUP_
DEFAULT_CHAR
--
Specify the
character to be
used to indicate
that the processor
group symbol is
using the default
from the PROC
statement of the
processor.
PROCESSOR_
GROUP_
OVERRIDE_
CHAR
Specify the
character to be
used to indicate
that the processor
symbol has been
overridden by the
processor group
symbol.
Quick-Edit ISPF
display option. If
set to N, display
includes elements
in Stage 1 and
Stage 2. If set to Y,
display includes
elements from all
stages and
environment in
the map.
QE_BUILD_
USING_MAP
Y or N
ISPF Dialog
Field Name
Current
Default
Panel Field
Description
QE_GENERATE_ Y or N
IN_PLACE
Quick-Edit ISPF
panel action
option. If Y,
element will be
generated in the
stage where it is
found. If N,
element will be
copied back into
the entry stage.
QE_RETURN_
FIRST_FOUND
Y or N
If Y, returns only
the first occurence
of the requested
element(s). If N,
returns all
occurrences of the
requested
element(s) found
along the map
route.
REPLACE_
MEMBER
Y or N
Replace an
existing member
in a partitioned
data set.
RETAIN_
SIGNOUT
Y or N
Retain the signout

during move or
transfer
processing.
RETURN_
FIRST_FOUND
Y or N
Include only the

first occurrence of
the element found
in the
environment map.
SHARABLE_
PACKAGE
Y or N
Identify whether a
package is
sharable.
SHOW_TEXT
Y or N
Show text during

list action
processing.
Valid
Values
Action,
Filter, or
Other
ISPF Dialog
Field Name
Valid
Values
Current
Default
Panel Field
Description
Action,
Filter, or
Other
SIGNIN_
MODE
F or B
Default mode
when executing
the signin action
in Quick-Edit; F
for foreground, B
for batch.
SIGNOUT_
ELEMENT
Y or N
Signout an
element during
RETRIEVE
processing.
SIGNOUT_
MODE
F or B
Default mode
when executing
the signout action
in Quick-Edit; F
for foreground, B
for batch.
SORT_BY_
1 or 2 or 3
DESTINATION_
ID
Sort the package

shipment list by
destination ID.
SORT_BY_
PACKAGE_ID
1 or 2 or 3
Sort the package

shipment list by
package ID.
SORT_BY_
SHIP_DATE
1 or 2 or 3
Sort the package

shipment list by
shipment date.
SYNCHRONIZE
Y or N
Create a
synchronization
level as part of
move or transfer
processing.
UPDATE_IF_
PRESENT
Y or N
Update an
element on an
ADD action if the
element already
exists at the entry
stage.
VALIDATE_
COMPONENTS
Y or N or W
See the
Note at
the end
of this
table
Validate the
components of a
package as part of
cast processing.
ISPF Dialog
Field Name
Valid
Values
Current
Default
Panel Field
Description
Action,
Filter, or
Other
WITH_HISTORY Y or N
Maintain the
element change
history.
WORKLIST_
PRIMARY
1 to 999
Set the primary

defaults for the
WORK DATASET
ALLOCATION
and the LIST
DATASET
ALLOCATION.
WORKLIST_
SECONDARY
1 to 999
Set the secondary

defaults for the
WORK DATASET
ALLOCATION
and the LIST
DATASET
ALLOCATION.
Note: For VALIDATE_COMPONENTS the default value depends on the

value of the PKGCVAL= parameter in the Endevor Defaults Table.
12.3.1 JCL (BC1JCNFG)

The JCL shown below can be used to assemble and link-edit the ISPF
configuration table. This JCL is provided on the Endevor installation files, 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=496K,
//
PARM=('NOTERM,NODECK,LIST,OBJECT,XREF(SHORT)')
//SYSUT1
//SYSUT2
//SYSUT3
//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)
//LINK
EXEC PGM=IEWL,
//
REGION=248K,
//
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=124
//SYSLMOD DD DISP=SHR,DSN=iprfx.iqual.AUTHLIB(ENDICNFG)
Chapter 13. The Defaults Table
Chapter 13. The Defaults Table 13-1
13.1 Overview
13.1 Overview
This chapter provides detailed information about the Endevor Defaults Table
(C1DEFLTS), and explains how to update it. The sections are:
Overview
The TYPE=MAIN Macro
The TYPE=ENVRNMNT Macro
The TYPE=END Macro
13.1.1 About the Defaults Table

The Endevor Defaults Table contains your global system information, such as
Endevor options installed at your site, Endevor control data set names, and
settings available for Endevor features. Although all of these parameters are
set at system installation, you may need to change the Defaults Table if your
site purchases a new Endevor product, your library names change, or you
want to tailor the information entered by the system installer. The table
comprises a set of "C1DEFLTS" macros which, when assembled and
link-edited, are known collectively as the Defaults Table.
The Defaults Table should reside in an authorized data set.
13.1.2 The C1DEFLTS Macro

There are three occurrences of the C1DEFLTS macro:
TYPE=MAIN macro defines site-specific information. It must be the first
macro specified in the table source. Only one TYPE=MAIN macro can be
specified.
TYPE=ENVRNMNT macro defines environment information. You can have
any number of these macros in the table, but you must have one macro for
each environment in your configuration. The TYPE=ENVRNMNT macros
follow the TYPE=MAIN macro.
TYPE=END indicates the end of the table definition. It follows the last
TYPE=ENVRNMNT macro.
13.1.3 Editing the Defaults Table

When you edit the C1DEFLTS macro, follow standard IBM rules.
Place all macro specifications between columns 2 and 71.
To continue across lines, place an X in position 72 and start the
continuation card at position 16 of the next line. Leave at least one blank
space between the end of one card (usually a comma) and the continuation
character in position 72.
13.1 Overview
Include at least one space between the macro nameC1DEFLTSand the

first keyword parameterTYPE.
Within each parameter specification, do not include any spaces. If you are
using literal operands that include a space, enclose the operand in single
quotes.
13.1.4 Warning
When editing the macros, pay special attention to the comma and continuation
character (X) that follow all but the last parameter within each macro. If either
of these are inadvertently deleted, the table assembles with a return code of
zero, but problems will result at Endevor execution.
13.1.5 Assembling the Defaults Table

When you have edited the Defaults Table, you need to assemble and link-edit
the table. Use BC1JDEFT JCL, shown below, to do this. Store the load module
in your authorized library as member C1DEFLTS.
If you have not already done so, copy your JOBCARD member to the
beginning of BC1JDEFT. Be sure the edited macros are placed correctly in the
job stream, then submit the job for execution.
//(JOBCARD)
//-------------------------------------------------------------------
//

// (C) 22 Computer Associates International, Inc. (CA)

//

// 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

//

//-------------------------------------------------------------------
//ASM
EXEC PGM=ASMA9,
//
REGION=372K,
//
PARM='NODECK,OBJECT,NOTERM,LIST,XREF(SHORT)'
//SYSLIB
//SYSLIN
DD DSN=&&SYSLIN,
//
UNIT=tdisk,
//
SPACE=(TRK,(3,5)),
//
//
//SYSPUNCH DD DUMMY
13.1 Overview
//SYSUT1
DD
//SYSPRINT DD
//SYSIN
DD
UNIT=tdisk,SPACE=(TRK,(5,15))
SYSOUT=

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

//

//-------------------------------------------------------------------
//LINK
EXEC PGM=IEWL,
//
REGION=248K,
//
PARM='LIST,NCAL,XREF,LET,RENT,REUS',
//
COND=(,NE)
//SYSLIN
DD DSN=&&SYSLIN,
//
//SYSLMOD DD DISP=SHR,DSN=uprfx.uqual.AUTHLIB(C1DEFLTS)
//SYSUT1
The job steps in job BC1JDEFT do the following:
Step
Action
Step 1
Assembles macros and passes the assembled Defaults Table

to Step 2.
Step 2
Link-edits the Defaults Table and stores it in the load

module into uprfx.uqual.AUTHLIB as member C1DEFLTS.
13.2 The TYPE=MAIN Macro

13.2.1 Example
The TYPE=MAIN macro defines site-specific information. It must be the first
macro specified in the table source. Only one TYPE=MAIN macro can be
specified.
The TYPE=MAIN macro is shown below.
C1DEFLTS TYPE=MAIN,
ACCSTBL=,
ACCESS SECURITY TABLE NAME
ACMROOT=,
ACM INDEX ROOT DATA SET NAME
ACMXREF=,
ACM INDEX XREF DATA SET NAME
APRVFLG=N,
APPROVAL PROCESSING (Y/N)
ASCM=N,
ACM CONTROL OPTION
AUTHTBLS=REQUIRED,
REQUIRED|ALLOW|IGNORE
BATCHID=,
BATCH UID FROM JOBNAME/USER=
CA7CCINODE=,
CA-7 ADDR SPACE NODE (CAICCI)
CA7JCLID=,
CA-7 JCL DATASET INDEX NUMBER
CA7JCLLIB=,
CA-7 JCL DATASET SYMBOIC INDEX
CA7JCLDSN=,
CA7JCLID/CA7JCLLIB DSNAME
CIPODSN=,
CCID VALIDATION DATASET NAME
CUNAME=' PUT YOUR COMPANY NAME HERE ', (5 CHAR)
DB2=N,
DB2 CONTROL OPTION
EDITELM=N,
EDIT ELEMENT DIALOG OPTION
ELINK=N,
ENDEVOR/LINK CONTROL OPTION
ELNKXTBL=,
E/LINK DATA STREAM XLATE TBL
ELMCATL='UPRFX.UQUAL.ELMCATL',
E/MVS CATALOG
ELMCATE='UPRFX.UQUAL.ELMCATE',
E/MVS CATALOG EINDEX
ESSI=N,
ESI CONTROL OPTION
GNIPSOUT=Y,
GENERATE INPLACE
INFO=N,
INFO/MAN CONTROL OPTION
JRNLGRP=,
PITR JOURNAL GROUP ID
LIBENV=,
LIBRARIAN (LB), PANVALET (PV)
LIBENVP=N,
LIBRARIAN/PANVALET OPTION
LIBRPGM=,
LIBRARIAN BATCH PROGRAM NAME
LINESPP=6,
LINES PER PAGE
MACDSN='IPRFX.IQUAL.SOURCE',
E/MVS SOURCE LIBRARY
MIXEDFMT=,
ALL|(CCID,COMMENT,DESCRIPTION)
MODHLI=,
HLQ FOR TEMPORARY DATA SETS )
NMAN=N,
CA-NETMAN INTERFACE OPTION
PARMLIB=,
ENDEVOR PARMLIB DATA SET NAME
PDM=N,
PDM CONTROL OPTION
PKGDSN='UPRFX.PACKAGE.MASTER',
PACKAGE DATASET
PKGTSO=N,
FOREGROUND PACKAGE EXEC (Y/N)
PKGCSEC=N,
PACKAGE CAST SECURITY (Y/N)
PKGCVAL=O,
PKG COMPONENT VALIDATION Y/N/O
PKGSEC=APPROVER,
APPROVER/ESI/MIGRATE
PRBLKSZ=,
BLKSZE PROC LISTING
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
PRLNKSZ=(896K,96K),
PRLSTSZ=1,
PROC=N,
RACFGRP=,
RACFPWD=,
RACFUID=,
RJCLROOT=,
SITEID=,
SYMBOLTBL=,
SMFREC#=,
SOFETCH=N,
SPFEDIT=SPFEDIT,
SYSIEWL=SYSIEWLP,
TYPESEQMBR=,
UIDLOC=(1,7),
VIOUNIT=TDISK,
WRKUNIT=TDISK,
WORKVOL=
LINKAGE SIZE FOR PROCS

SIZE ALLOC FOR PROCS LISTINGS
PROCESSOR OPTION
ALTERNATE ID RACF GROUP
ALTERNATE ID PASSWORD
ALTERNATE ID USERID
SHIP REMOTE JCL MODEL MBR ROOT
ENDEVOR/MVS SITE IDENTIFIER
SITE-DEFINED SYMBOL TBL NAME
SMF RECORD NUMBER
SIGNOUT UPON FETCH
(Y/N)
DEFAULT PDS RESERVE
DEFAULT PDS/LINK EDIT RESERVE
ENDEVOR TYPE SEQ MBR
UID/JOBNAME START/LENGTH POS
UNIT FOR VIO-ELIGIBLE ALLOC
UNIT NAME FOR WORK SPACE
VOL SER NUMBER FOR WRKUNIT
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Each TYPE=MAIN parameter is defined in the table below.

Parameter
Definition
ACCSTBL
The 1- to 8-character name of the Endevor Access

Security Table used at your site. You must enter a
valid name.
If you are using native security and leave the field
blank, no security checking will be done.
If you are using the Endevor ESI feature and leave
this field blank, the Access Security Table name
defaults to BC1TNEQU.
ACMROOT
The data set name of the VSAM file your site will
use to store the name of each Endevor element and
all its related components. The recommended name
is uprfx.uqual.ACMROOT.
This data set is required if your site plans to use the
ACM Query Facility.
See the Automated Configuration Option Guide for
more information.
ACMXREF
The data set name of the VSAM file you will use to
store the name of each component relationship. The
recommended name is uprfx.uqual.ACMXREF.
The data set is required if your site plans to use the
ACM Query Facility.
See the Automated Configuration Option Guide for
more information.
Parameter
Definition
APRVFLG
Indicates whether approval processing is required.

Set this parameter to Y if approval processing is
required.
If you set this parameter to N, approval processing
will not be active no matter what approver group
relationships have been defined.
ASCM
Indicates whether the Endevor Automated

Configuration Manager (ACM) facility is enabled at
your site. If your site is using ACM, specify Y.
Otherwise, specify N.
For more information, see the Automated
Configuration Option Guide.
AUTHTBLS
Indicates whether Endevor's security tables must be

loaded from authorized libraries. Values are:
REQUIREDAuthorized libraries are required.
This is the default value.
ALLOWUnauthorized libraries are allowed,
but Endevor will issue a warning message.
IGNOREEndevor does not check the libraries'
authorization.
BATCHID (Required
entry)
Indicates whether the Endevor user ID associated

with a batch job should be determined by the
JOBNAME or the USER parameter specified on the
jobcard. Values are:
0determined by JOBNAME (this is the default
value)
1determined by the USER parameter
2determined by the USER parameter if
specified, otherwise by the JOBNAME
See "Selecting a BATCHID Option" later in this
appendix.
CA7CCINODE
Specifies the CAICCI node name where the CA-7

address space executes. If no name is specified,
local mode is assumed.
CA7JCLID
Provides Endevor with the CA-7 parameter

information required by CA-7 to schedule JOB
execution. Parameter values should be obtained
from the CA-7 implementation. Mutually exclusive
with CA7JCLLIB.
Parameter
Definition
CA7JCLLIB
Provides Endevor with the CA-7 parameter

information required by CA-7 to schedule JOB
execution. Parameter values should be obtained
from the CA-7 implementation. Mutually exclusive
with CA7JCLID.
CA7JCLDSN
The data set name associated with CA7JCLID or

CA7JCLLIB.
CIPODSN
The data set name of the sequential file your site

plans to use to store valid CCID values. The
recommended name is uprfx.uqual.VALCCID.
This data set is required if you want to use the
CCID validation facility.
See the Administrator Guide for more information.
CUNAME (Required
entry)
The 1- to 50-character name that describes your site.

This name is used in report headings.
DB2
Indicates whether the Endevor for DB2 application

is enabled at your site. If your site is using Endevor
for DB2, specify Y. Otherwise, enter N.
For more information, see the Endevor for DB2 Guide.
EDITELM
Indicates whether the Endevor Quick Edit feature is

enabled at your site. If your site is using this
feature, specify Y. Otherwise, enter N.
For more information, see the Quick Edit Option
Guide.
ELINK
Indicates whether Endevor Link is enabled at your

site. If your site is using Endevor Workstation
product, specify Y. Otherwise, enter N.
For more information, see the letter that
accompanies the Endevor Link tape.
ELNKXTBL
Defines the ELink translation tables. See the

Endevor Link Administrator Guide for more
information.
ELMCATL
The 1-44 character data set name of the element

catalog VSAM file. Endevor uses the Element
Catalog file to support long element names and to
boost performance by reducing the volume of I/O
operations.
Parameter
Definition
ELMCATE
The name of the element catalog EINDEX VSAM

file. If left blank, the name will default to the name
specified for ELMCATL with a suffix of .EINDEX. If
you are currently using an EINDEX and you leave
the ELMCATE field blank, the name defaults to the
name you are currently using.
ESSI
Indicates whether the Endevor ESI facility is

enabled at your site. If your site is using Endevor
ESI, specify Y. Otherwise, enter N.
For more information, see the Security Guide.
Note: Do not activate this option until all of the
security rules are written and in place.
GNIPSOUT
Indicates whether Endevor is to perform a Generate

in-place with or without signout.
When GNIPSOUT=Y, an element will be signed out
to a user who performs a Generate in-place action.
This is the default.
When GNIPSOUT=N, an element will retain its
original signout setting. Endevor will not signout
an element to a user who performs a Generate
in-place action.
INFO
Indicates whether the Endevor

Information/Management interface (Info/Man) is
enabled at your site. If your site is using Info/Man,
specify Y. Otherwise, enter N.
For more information, see the Interface for IBM Tivoli
Information Management Administration Guide.
Note: Do not activate this option until the
Information/Management interface is fully installed.
Parameter
Definition
JRNLGRP
An L-Serv journal group ID which, when entered,

relates the package data set named in this macro to
a specific set of L-Serv journal files. Use of this
parameter enables journaling in the Package Control
File.
The format is: (gggg,nnnn)
Values are:
ggggThe journal group ID associated with the
package journal files.
nnnnThe journal group subsystem ID.
For more information, see the Utilities Guide.
LIBENV
This parameter serves two purposes depending

upon the LIBENVP parameter.
If LIBENVP=Y,then
LIBENV=PV indicates that Panvalet is
installed;
LIBENV=LB indicates that Librarian is
installed.
If LIBENVP=N (default), then the include
member syntax is used by CONWRITE and/or
the Expand Include Utility as follows:
LIBENV=PV tells Endevor to check for
Panvalet include member syntax
(++INCLUDE) or COBOL COPY statements,
LIBENV=LB tells Endevor to check for
Librarian include member syntax (-inc) or
COBOL COPY statements
LIBENV=blank (default), no syntax checking
or expanding will occur.
LIBENVP
Indicates whether your site is using Librarian or

Panvalet with Endevor. If your site is using one of
these library management applications, specify Y.
Otherwise, N.
LIBRPGM
Applicable only if the LIBENV value is LB. This is

the name of the Librarian load module for your site.
LINESPP
The number of lines per printed page for output

generated by Endevor. Default is 60. Valid entries
are 1-99.
Parameter
Definition
MACDSN (Required
entry)
The data set name of the library containing the

Endevor macros. This library was created during
the Endevor installation procedure. The
recommended name is iprfx.iqual.SOURCE.
The data set is used by many Endevor functions
and is required.
MIXEDFMT
Determines whether Endevor accepts mixed-case

entries in CCID, COMMENT, and DESCRIPTION
fields. Values are:
CCIDAccept mixed case in CCID fields.
COMMENTAccept mixed-case in COMMENT
fields.
DESCRIPTIONAccept mixed-case in
DESCRIPTION fields.
ALLAccept mixed-case in all three fields.
NONEDo not accept mixed-case in any field.
Multiple values can be specified by enclosing the
values in () and separating them by a comma. For
example, =(CCID,COMMENT).
Parameter
Definition
MODHLI
Allows you to assign a prefix other than SYSyyddd

to a temporary data set, creating a
pseudo-temporary data set. This applies to those
temporary data sets which are allocated DISP=MOD
at any step in a processor only. Regular temporary
data sets, which are not DISP=MOD, use the
standard z/OS temporary data set name. This prefix
appears 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 when
allocating, deleting, and opening files for output.
The effective name generated is:
modhli.Dyyddd.Thhmmss.RA0.jobname.ddname
Values are:
modhlithe data specified in the MODHLI
operand
yydddthe Julian date
hhmmssthe time in hours, minutes, and
seconds
jobnamethe same value as jobname
ddnamethe DDname specified in the
processor JCL
RA0 is used instead of RA000 to make room for
8-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 is

enabled at your site. If your site is using the
Netman Interface, specify Y. Otherwise, enter N.
See the Interface for CA-Netman Administration Guide
for more information.
PARMLIB
Indicates the Parmlib data set name, which is

required to implement the Global Type Sequencing
option, because it is used to contain the Type
Sequence member.
Parameter
Definition
PDM
Indicates whether the Endevor Parallel

Development Manager (PDM) facility is enabled at
your site. If your site is using PDM, specify Y.
Otherwise, enter N.
For more information, see the PDM User Guide.
PKGDSN (Required
entry if you are using
packages)
The data set name of the VSAM file your site will
use to store package information. This library was
created during the Endevor installation procedure.
The recommended name is uprfx.uqual.PACKAGE.
The data set is required if your site plans to use any
of the package processing features.
See the Packages Guide for more information.
Be sure you use the same data set name for both
definition of and allocation of the package data set.
PKGTSO
Indicates whether foreground package processing is

allowed. Set this parameter to Y if foreground
processing is allowed at your site. Otherwise, set the
parameter to N.
When a processor runs as part of a package, the
PKGTSO flag overrides the foreground execution
flag in the processor group. This means that if
PKGTSO=Y, all processors in that package will
execute, regardless of the value in the foreground
execution field for the processor group.
PKGCSEC
Indicates whether actions should incur a security

check at package cast time. Set this parameter to Y
to have each Endevor action checked during the
package cast operation.
If you set this parameter to N, no action security
check is performed during the package cast
operation.
PKGCVAL
Indicates whether component validation is required

when packages are cast. Values are:
YComponent validation is required, no matter
who is working with the package.
OComponent validation is optional. Whether
validation takes place is determined by the
person working with the package.
Parameter
Definition
PKGSEC
Indicates the type of security which controls the

package options.
APPROVERThis value indicates that the site
would like to restrict package actions to package
approvers.
ESIIndicates that the site would like to
control package options through an external
security package such as ACF/2, Top Secret,
and IBM RACF via the ESI interface.
MIGRATEIndicates that the site is in
transition between Approver security and ESI
security. Both will be checked.
Note: The approver security rules take
precedence over ESI security rules. If the user
is granted access to the package by the approver
rules, ESI will not be invoked. ESI will be
invoked only when the user does not belong to
any approver groups associated with the
package (If there are no approver groups
associated with the package (this is true for
ALL packages before they are CAST), no access
restrictions apply.)
PRBLKSZ=0
Indicates the blocksize to be used for temporary

files when compiling processors. If you are on a
version of z/OS that does not support BLKSIZE=0,
you must specify the value for this parameter that is
a multiple of 121.
PRLNKSZ=(256K,64K)
Indicates the size parameter used by the linkage

editor. When adding very large processors with
many symbolics, this parameter may need to be
increased. For example, use (384K,64K).
PRLSTSZ=10
The value of PRLSTSZ is used for both the primary

and secondary space allocation parameters (in
cylinders) for processor listings. The value of
PRLSTSZ may need to be increased for very large
processors.
PROC
Indicates whether processors are enabled at your

site. If your site is using processors, specify Y.
Otherwise, enter N.
For more information, see the Extended Processors
Guide.
Parameter
Definition
RACFGRP
The name of the security group with which the

alternate user ID (RACFUID) is associated. This is
an optional parameter.
RACFPWD
The security password for the defined alternate user

ID. This is an optional parameter.
RACFUID
The alternate user ID for data set authorization

checking.
RJCLROOT
Controls the choice of remote JCL generation. There

are three choices:
RJCLROOT - Not specified. Causes the job
stream to be programatically generated without
the use of model members.
RJCLROOT=FCPY which specifies the job
stream is generated through a set of model
members beginning with the character string
#RJFCPY
RJCLROOT=ICPY which specifies the job stream
is generated through a set of model members
beginning with the character string #RJICPY
SITEID (Required
entry)
The 1-character name that identifies your site. It is

used 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 Endevor
installations will result in a footprint-compromised
error for each element within that installation's
environments.
SYMBOLTBL
Indicates the name of the symbolics table in use at

your site if you are using site-defined symbolics.
See the section, Site-Defined Symbolics in Chapter
3 for more information.
SMFREC#
The SMF record number assigned to SMF records

written by ENDEVOR at this site. Set this value to 0
(zero) until you implement the optional SMF
interface.
If you want to write out SMF Action Records or
SMF Security Records or both, you must enter a
value for this parameter. The parameters
controlling which records are actually written are
SMFACT and SMFSEC in the TYPE=ENVRNMT
macro. For more information, see SMFACT.
Parameter
Definition
SOFETCH
Indicates whether the element that is fetched should

be signed out to you, if not already signed out to
someone 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.
See the User Guide for a table that shows how
SOFETCH values together with actions affect
signout.
SPFEDIT
The queue name used when Endevor issues an

enqueue on a sequential file or partitioned data set
(not RECFM=U). This may be a source library,
object library, or other user library. Default is
SPFEDIT.
The resource name for the enqueue name is the data
set name.
SYSIEWL
The queue name used when Endevor issues an

enqueue on a partitioned data set defined with
RECFM=U (for example, a load library). Default is
SYSIEWL.
The resource name for the enqueue is the data set
name.
TYPESEQMBR
Indicates the name of the Type Sequence member,

which enables Global Type Sequencing. The Type
Sequence member defines the type sequence order
in which element actions are processed at your site,
regardless of the action's inventory location. If you
specify this parameter, you must also specify the
Parmlib data set parameter. An empty Type
Sequence member will force type sequencing by
type name order.
UIDLOC
The character positions of the user ID that should

be compared for ownership (that is, for element
signout and signout override check) in batch. You
specify a starting position and number of characters.
For example, if you wanted to take the first three
characters of the user ID, then you would specify
UIDLOC=(1,3). Default is the first seven characters:
UIDLOC=(1,7).
VIOUNIT (Required
entry)
The unit name for temporary disk data sets that are
stored on a virtual I/O unit.
Parameter
Definition
WRKUNIT (Required
entry)
The unit name for temporary disk data sets that are
not stored on a virtual I/O unit.
WORKVOL
The volume serial number of the disk used to store

temporary data sets.
13.3 The TYPE=ENVRNMNT Macro

13.3.1 Example
The TYPE=ENVRNMNT macro defines environment information. You can
have any number of these macros in the table, but you must have one macro
for each environment in your configuration. The TYPE=ENVRNMNT macros
follow the TYPE=MAIN macro.
The TYPE=ENVRNMNT macro is shown below:
ENDBACT=N,
ENDBAVL=N,
ENTRYSTG#=1,
ENVNAME='Environment Name',
ENVTITL='Environment Title',
JRNLGRP=,
NEXTENV=(Environment Name,Stage ID),
RSCETBL=,
SMFACT=N,
SMFSEC=N,
STG1ID=Stage 1 ID,
STG1NME='Stage 1 Name',
STG1TTL='Stage 1 Title',
STG1VSM='Stage 1 MCF Data set name',
STG2ID=Stage 2 ID,
STG2NME='Stage 2 Name',
STG2TTL='Stage 2 Title',
STG2VSM='Stage 2 MCF Data set name',
USERTBL=
To specify more than one environment, copy this macro as many times as
necessary.
Note: If you are creating an environment map, you need to specify the next
environment in each definition. Make sure that you code them in the proper
order, starting with the first environment and continuing to the last
environment (in other words, start with the top and work down).
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
The illustration below shows an example for three environments:

.
.
.
USERTBL=
.
.
.
USERTBL=
.
.
.
USERTBL=
Each TYPE=ENVRNMNT macro is defined in the table below:

Parameter
Definition
ENDBACT
ENDBAVL
Parameters related to the Endevor/DB-MVS Bridge.

For more information, see the Endevor to
CA-Endevor/DB Administrator Guide.
ENTRYSTG#
Indicates the entry stage, either 1 or 2, for the

environment. If this parameter is not defined, the
entry stage defaults to 1.
ENVNAME
(Required entry)
The 1- to 8-character name of the Endevor

environment to which this macro applies. This value
must be unique within this Defaults Table (that is, to
this site). The name can include any of (but only) the
following characters: A-Z, 0-9, @, #, $.
ENVNAME is an integral part of the Endevor
footprint. Any change to this parameter for existing
z/OS environments will result in a
footprint-compromised error for each element within
that environment.
ENVTITL
(Required entry)
The 1- to 40-character descriptive title for the

environment.
Parameter
Definition
JRNLGRP
An L-Serv journal group ID which, when entered,

relates the Master Control Files named in this macro
to a specific set of L-Serv journal files. Use of this
parameter enables journaling in the Master Control
File base and delta libraries (both VSAM and
non-VSAM).
The format is: (gggg,nnnn)
Values are:
ggggThe journal group ID associated with the
MCF and delta journal files.
nnnnThe journal group subsystem ID.
For more information, see the Utilities Guide.
NEXTENV
The next environment/stage location on the

environment map. The format is: (environment name,
stage id)
Values are:
environment nameThe 1- to 8-character name
of the next environment.
stage idThe identifier (1 or 2) of the stage in
that environment. If you do not provide a stage
ID, Endevor defaults to STAGE ID=1.
For more information on maps, see the Administrator
Guide.
RSCETBL
The 1- to 8-character name of the Endevor Resource

Security Table for this environment. The Resource
Security Table allows you to restrict one or more
elements to a specific system(s) and subsystem(s)
within an environment. Define one Resource Security
Table for each environment (as necessary).
Leave this field blank if you do not want to restrict
elements to a specific system(s) and subsystem(s). If
you do want to use restriction, fill in this field and
prepare the Resource Security Table as described in
the Security Guide (only applies to native security).
Parameter
Definition
SMFACT
Indicates whether Endevor should write out SMF

Action Records. Set this parameter to Y if you want
Action Records written out. Otherwise, set the
parameter to N. Default is N.
If you set this parameter to Y, you must specify a
value for the SMFREC# in the TYPE=MAIN macro. If
you do not specify SMFREC#, Endevor ignores the
SMFACT parameter.
See the Administrator Guide for more information on
SMF Recording.
SMFSEC
Indicates whether Endevor should write out SMF

Security Records. Set this parameter to Y if you want
Security Records written out. Otherwise, set the
parameter to N. Default is N.
If you set this parameter to Y, you must specify a
value for the SMFREC# in the TYPE=MAIN macro. If
you do not specify SMFREC#, Endevor ignores the
SMFSEC parameter.
For more information, see the Administrator Guide.
STG1ID (Required
entry)
The 1-character identifier for the first stage, used

during processing to select (or identify) the stage you
want. Commonly used identifiers are 1 or A. Default
is 1.
STG1NME
(Required entry)
The 1- to 8-character name assigned to Stage 1 for

this environment. The stage name must be unique
across all environments within a site (that is, within
the Defaults Table). The stage name can include any
of (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 first

stage. This name is used on various panels and
reports to describe this stage.
STG1VSM
(Required entry)
The Master Control File data set name for Stage 1, as

defined during installation. The data set name
defaults to: uprfx.uqual.STAGE1.
STG2ID (Required
entry)
The 1-character identifier for the second stage, used

during processing to select (or identify) the stage you
want. Commonly used identifiers are 2 or B. Default
is 2.
Parameter
Definition
STG2NME
(Required entry)
The 1- to 8-character name assigned to Stage 2 for

this environment. The stage name must be unique
across all environments within a site (that is, within
the Defaults Table). The stage name can include any
of (but only) the following characters: A-Z, 0-9, @, #,
$
STG2TTL
(Required entry)
The 1- to 20-character descriptive title for the second

stage. This name is used on various panels and
reports to describe this stage.
STG2VSM
(Required entry)
The Master Control File data set name for Stage 2, as

defined during installation. The data set name
defaults to: uprfx.uqual.STAGE2.
USERTBL
The 1- to 8-character name of the Endevor User

Security Table for this environment. The User
Security Table allows you to control the systems and
subsystems available to all users within an
environment. Define one User Security Table for each
environment (as necessary).
Leave this field blank if you do not want to control
systems and subsystems within an environment. If
you do want to control the availability of systems
and subsystems, fill in this field and prepare the
User Security Table as described in the Security Guide
(only applies to native security).
13.3.2 Selecting a BATCHID Option

When executing Endevor element actions in batch (C1BM3000) Endevor uses
the values specified for BATCHID and UIDLOC in the C1DEFLTS table to
derive the value to be used as the Endevor userid.
The BATCHID parameter is specified in the TYPE=MAIN section of your
C1DEFLTS table. It determines whether the Endevor userid associated with a
batch job will be determined by the JOBNAME, the USER= parameter
specified on the jobcard the userid of the submitter. One of the following
values must be specified:
0-- determined by JOBNAME (this is the current default value, future
releases will default to 2).
1-- determined by the USER parameter, or if not present, the userid of the
submitter.
2-- determined by the USER parameter (or submitter as described above) if
specified, otherwise by the JOBNAME.
The UIDLOC parameter of the C1DEFLTS table (also TYPE=MAIN), tells us

the character positions of the Endevor userid that should be compared for
ownership, (that is, for element signout/override signout check) in batch.
UIDLOC specifies the starting position and the number of characters. The
default is the first seven characters UIDLOC=(1,7).
In the following example, user PAND and user NDVR attempt to RETRIEVE
an element that is currently "owned" by user NDVR. UIDLOC=(1,4). Neither
user has the authority to use the "OVERRIDE SIGNOUT" option. The
following chart shows the results of their attempts:
JOBNAME
ABCDJ
ABCDJ
ABCDJ
ABCDJ
PANDJ
PANDJ
PANDJ
PANDJ
NDVRJ
NDVRJ
NDVRJ
NDVRJ
SUBMITTER
PAND
PAND
NDVR
NDVR
PAND
PAND
NDVR
NDVR
PAND
PAND
NDVR
NDVR
Userid Assigned by Endevor/Action Allowed (Y/N)

USER= (1)
BATCHID= (2) BATCHID=1
BATCHID=2
PAND
ABCD/N
PAND/N
PAND/N
n/a
ABCD/N
PAND/N
PAND/N
NDVR
ABCD/N
NDVR/Y
NDVR/Y
n/a
ABCD/N
NDVR/Y
NDVR/Y
PAND
PAND/N
PAND/N
PAND/N
n/a
PAND/N
PAND/N
PAND/N
NDVR
PAND/N
NDVR/Y
NDVR/Y
n/a
PAND/N
NDVR/Y
NDVR/Y
PAND
NDVR/Y(2)
PAND/N
PAND/N
n/a
NDVR/Y(2)
PAND/N
PAND/N
NDVR
NDVR/Y
NDVR/Y
NDVR/Y
n/a
NDVR/Y
NDVR/Y
NDVR/Y
Notes
1. Several security packages have an optional feature to automatically append
the user=/password= parameters on the job card at job submission. If this
is the case at your shop, then BATCHID=1 is recommended.
2. Many sites have job submission exits that ensure the jobname matches the
submitter's userid. If your site does not utilize this feature, it is strongly
recommended you DO NOT USE BATCHID=0.

13.4.1 Example
The TYPE=END macro indicates the end of the table definition. It follows the
last TYPE=ENVRNMNT macro.
The TYPE=END macro is shown below:
C1DEFLTS TYPE=END
Do not change this macro.
Chapter 14. The Alternate Defaults Table
Chapter 14. The Alternate Defaults Table 14-1
14.1 About ENUXSITE
14.1 About ENUXSITE

This appendix explains how to use the ENUXSITE exit to select an alternate
14.1.1 What Is the ENUXSITE Program?

ENUXSITE is an exit, called at Endevor initialization, that allows your site to
identify the name of an alternate Defaults Table based on a user ID or other
criteria. An alternate Defaults Table might be used as a mechanism to test a
new configuration at your site. Or, you may want to provide a specific
Defaults 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 and
must reside in an authorized library. (See the discussion about authorized
programs and authorized libraries in the section Step 4: Populate the
Authorized Library with Endevor Modules.)
14.1.2 Parameters Passed to the ENUXSITE Program

When Endevor initializes a session, it searches the authorized library for a
user-written program named ENUXSITE. If the program is found, Endevor
passes to the exit, using standard linkage conventions, a single, 16-character
data field. The first eight characters of the field contain the name C1DEFLTS.
The remaining eight characters contain the user ID associated with the current
Endevor session.
Note: When running in batch, the value specified as the user ID will be either
one of the following:
The job name specified on the jobcard.
The value specified on the USER= parameter of the jobcard. This value, if
provided, takes precedence over use of the job name.
14.1.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 of
the Defaults Table you want to use. ENUXSITE returns control to Endevor
to 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 IDENTIFY
service to identify the table as the C1DEFLTS. The exit returns control to
Endevor, leaving the 16-character parameter unmodified.
14.1 About ENUXSITE
14.1.4 How to Create an Alternate Defaults Table

To create an alternate Defaults Table, follow the instructions provided in the
discussion Step 8: Work with the Endevor Defaults Table. Change the name
C1DEFLTS to the name you want to assign the alternate Defaults Table. Verify
that the link-edit output member name--DD SYSLMOD--specifies the correct
name.
14.1.5 Example
The example below shows a COBOL program written to allow USER1 to have
a different version of the Defaults Table than other users. The name of USER1'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 14. The Alternate Defaults Table 14-3
Chapter 15. Performance and Tuning
Chapter 15. Performance and Tuning 15-1
15.1 Overview
15.1 Overview
This chapter provides performance and tuning hints that can help you make
Endevor run efficiently in your environment.
Endevor's flexibility allows you to configure your system to meet your site's
goals and standards, but it also makes tuning difficult because each Endevor
installation is slightly different.
15.2 Choosing Between Delta Formats

15.2.1 Overview
Both forward and reverse deltas allow you to keep track of the changes made
to an element, and they have the same performance characteristics in terms of
storage. The difference is in what Endevor considers to be the base level.
For forward deltas, the base element is the original code, and the delta
levels correspond to the changes made to that code. When you want a
copy of the latest version of an element, Endevor has to merge the base
and delta levels using the CONWRITE utility.
Forward deltas are useful when elements are relatively stable, because
when the element is saved, Endevor only writes the changes to a file and
does not rewrite the full source text.
For reverse deltas, the base element is the current copy of the code, and
the delta levels contain the information needed to return the element to its
original form. When you want a copy of the latest version of an element,
Endevor (or any other program) can ignore the delta levels and simply
read the base element. This also improves processor performance, because
Endevor does not need to invoke the CONWRITE utility to rebuild the
element.
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 in
addition to saving the changes in the delta library.
Note: Backout processing requires a source output library that cannot be the
same data set as the reverse delta base library.
In summary:
Delta Type
I/O
operations
needed
Read
I/O
operations
needed
Write
Use for elements that:
Forward
Are updated more than they

are read.
Are in production.
Reverse
Normally need a source output

library but don't need to be
backed out. These files need to
be kept in a standard format
(such as a PDS) for utilities such
as Advantage CA-File Master.
15.2.2 Converting from Forward to Reverse Deltas

For details about the conversion process, see Appendix A, Converting Delta
Formats.
15.2.3 Full-Image Deltas

Full-Image delta format should be chosen for machine-generated code, USS
binary 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 more
DASD.

15.3.1 Two Parameters
Element data consolidation is comprised of two functions: the "consolidation
level" and the "number of levels to consolidate".
The consolidation level (CONSOL AT LVL) specifies when the
consolidation process is initiated. This is the maximum number of levels
you want stored on the system.
Example: The CONSOL AT LVL parameter is set to 96. When the
number of levels reaches 97, Endevor begins the consolidation process.
Note: For the most efficient level consolidation across environments, set
this parameter to the maximum value of 96.
The number of levels to consolidate (LVLS TO CONSOL) specifies the
number of levels to consolidate when the threshold is met.
Example: The LVLS TO CONSOL parameter is set to 25, the CONSOL AT
LEVEL (consolidation trigger) is set to 96. Prior to saving the 97th level,
Endevor:
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
- LVLS TO CONSOL
Minimum level
97
25
72
Determine the maximum and minimum number of levels you want to store on
the system. Using these values, you can calculate the number of levels to
consolidate (LVLS TO CONSOL). The maximum value is specified in the
consolidate level (CONSOL AT LVL) field. The minimum value is only used
for calculation purposes. The difference between the maximum value and the
minimum 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 to
rebuild, because each delta level requires additional I/O operations.
Note: Verify the parameter values match for the same element type across
different Endevor locations. For information on where to set the consolidation
level, see 3.7.3, Type Definition Panel on page 3-33.
15.4 Mapping Multiple Environments
15.4 Mapping Multiple Environments

15.4.1 Before Implementation
Before implementing Endevor, determine the number of environments you
need, and how the stages within those environments are connected. By
examining your site's requirements, you can build a software life cycle that
provides the most efficient path for your developers.
For example, the diagram below shows two environments (QA and PROD),
with links between the first and second stage in each environment, and
another link between stages HOLD and PROD.
This model cannot be implemented using the basic Endevor pathways, because
you can only enter an environment through a single entry stage. If developers
wanted to move an element from Stage HOLD to Stage PROD, they must use
the TRANSFER action instead of the familiar MOVE action. In order to solve
this problem, you can create Stage 2 to Stage 2 links by mapping the
environments in the Defaults Table. Mapping allows you to:
Create the logical equivalent of n stages.
Provide developers with the ability to MOVE, ADD, and RETRIEVE
elements between the linked stages.
Create multiple entry points into a software life cycle or join multiple life
cycles.
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 Chapter 4, Mapping
15.5 Selecting a Library Type for Base and Delta Members

15.5.1 Benefits of Library Types
You can store your Endevor data sets using PDS, PDS/E, Endevor LIB
(VSAM/BDAM), or AllFusion CA-Panvalet and AllFusion CA-Librarian. This
section discusses the benefits and drawbacks for each library type.
Medium
Benefits
Drawbacks
PDS
Provides a familiar and

standard means of
storage for the source.
No installation issues.
Members can be read
by other utilities such
as compilers.
Directory overhead
becomes inefficient if
there are more than
3-4K+ members.
Strict maintenance is
required to prevent x37
abends.
PDS/E
Low maintenance.
Current technology.
Members can be read
by other utilities such
as compilers.
Benchmarks show that

the performance is
slower than PDS or
Endevor LIB.
Does not allow EXCP
processing.
Medium
Endevor LIB
Benefits
Low maintenance.
Sophisticated set of
utilities to manage the
data sets.
BDAM is more efficient
for medium-sized
directories, and VSAM
is more efficient for
large directories, than
either PDS or PDS/E.
Directory overhead
routines are designed
for a large number of
members, thereby
increasing efficiency.
You can allocate a
VSAM ELIB across
multiple volumes. If
you initially allocate an
ELIB data set across
two volumes, Endevor
will honor that
allocation when ELIB
expansion occurs. The
expansion can be
automatic when the
page reserve limit is
reached or explicitly
performed through the
use of BC1PNLIB. This
is only for VSAM ELIB;
BDAM ELIB must be
allocated on a single
volume.
AllFusion
Accommodates the site
CA-Panvalet/AllFusionstandard.
CA-Librarian
Directory compression
issues are eliminated.
Source output file can
be read directly by
AllFusion
CA-Panvalet/
AllFusion CA-Librarian
utilities.
Drawbacks
VSAM options can
require a lot of
processing time.
Utilities are required for
expands, copies, etc.
Library members
accessible only through
Endevor.
With AllFusion
CA-Panvalet, conflicts
arise with Endevor
footprint and comment
information.
Library members are
only accessible through
AllFusion CA-Panvalet
and/or AllFusion
CA-Librarian.
15.5.2 Converting from One Library Type to Another

The BC1PNCPY utility copies data from one of the supported library format to
another supported format. This allows you to try different methods based on
your site's requirements. For example, you can copy an AllFusion
CA-Panvalet library to a PDS, or copy a PDS to Endevor LIB.
For more information about the BC1PNCPY utility, see the Utilities Guide.

15.6.1 Function
CA-L-Serv is a master started task that controls Endevor's VSAM files for
Master Control Files (MCFs), packages, and Endevor LIB (if you are using
VSAM 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.6.2 Setting the RECBUFFSIZE Parameter

When you install CA-L-Serv, set the RECBUFFSIZE parameter based on your
site's configuration. If you are using CA-L-Serv to manage:
Only MCFs and package data sets, set RECBUFFSIZE to 1K (the size of the
largest VSAM record in these files).
Endevor LIB VSAM files (with or without MCFs or packages), set
RECBUFFSIZE 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 to
the journal files in 12K increments.
15.6.3 Monitoring CA-L-Serv's Performance

The ongoing success of this feature requires periodic monitoring to ensure that
optimal performance benefits are achieved. You should monitor the system
when:
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 Common
Services CA-L-Serv Technical Bulletin.
15.6.3.1 Evaluating Buffer Pool Usage

To see how well your buffer pools are being used, issue the DISPLAY
BUFFERPOOL and DISPLAY STATISTICS SERVICE commands. For details,
see the Unicenter Common Services CA-L-Serv Technical Bulletin.
15.6.3.2 Displaying Information about the Communications Server

The DISPLAY command provides additional options to provide online
information about the Communication Server's activity. For details, see the
Unicenter Common Services CA-L-Serv Technical Bulletin.
15.7 Using z/OS SYSPLEX VSAM Record Level Sharing (RLS) Support for MCFs and Package Data Set
15.7 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 hierarchy
to support data sharing across multiple systems in a System/390 parallel
Sysplex. This feature, available on all z/OS Sysplex systems, offers Endevor
the performance and availability benefits of data sharing in a coupled-systems
environment.
As a new data access mode, VSAM RLS allows multisystem access to a VSAM
data set while ensuring cross-system locking and buffer invalidation. VSAM
RLS uses z/OS coupling facility (CF) services to perform data set level locking,
record locking, and data caching. VSAM RLS maintains data coherency at the
control interval level. It uses CF caches as store-through caches; when a
control interval of data is written, it is written to both the CF cache and to
DASD. This ensures that a failure in the CF cache does not result in the loss
of 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 control
blocks and the system-wide buffer pool used for data sets opened for
record-level sharing. SMSVSAM assumes responsibility for synchronizing this
control block structure across the parallel Sysplex.
With VSAM RLS, multiple Endevor systems can directly access a shared
VSAM data set, eliminating the need for Reserve/Release and Enqueues
between Endevor Users or Batch Jobs in order to maintain the integrity of the
Endevor VSAM data sets. VSAM RLS provides for serialization and
synchronization of data sets and cross-system caching. With VSAM RLS,
multiple Endevor Users or Batch Jobs can have concurrent read/write access to
Endevor 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 or
Journaling, the LOG attribute must be set to LOG(NONE).
At OPEN time, Endevor determines if the file is defined with VSAM RLS
support, and, if so, Endevor opens the file with RLS.
System administration determines when RLS is used. Typically, this
determination is made when the cluster is defined with the IDCAMS utility
program.
Sample JCL to enable RLS support may be found in iprfx.iqual.JCLLIB, member
BC1JDRLS.
VSAM Record Level Sharing provides several performance enhancements:
15.7 Using z/OS SYSPLEX VSAM Record Level Sharing (RLS) Support for MCFs and Package Data Set
The VSAM buffers for ALL jobs and/or TSO users are consolidated into
the SMSVSAM address space, increasing the chance of a record being in
memory
The SYSPLEX Lock Manager provides record level, CI level and CA level
locking between SYSPLEX systems
Due to the first two enhancements, Endevor is able to bypass its own
native Reserve/Release logic
The I/O performance of the SMSVSAM address space and the SYSPLEX
cache allows a significant reduction in the elapsed time required to do
update I/Os.
15.7.1 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 attributes
must 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.8 Tuning Your Processors
15.8 Tuning Your Processors

15.8.1 Recommendations
When you are tuning your processors, you should keep the following points in
mind:
Ensure that record formats (RECFMs), block sizes (BLKSIZEs), and logical
record lengths (LRECLs) are specified correctly for the program being
executed.
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-editor
data sets.
Avoid recursive executions of Endevor by making use of the CONWRITE
utility to output other elements. For example, if your jobcards are stored
in one file and need to be merged into every executable file, CONWRITE
can perform this merge without re-invoking Endevor. For more
information 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 extra
steps that may have been required in the past.
Allocate all temporary sequential data sets with BC1PDSIN to ensure that
they are available for other programs such as CONLIST. Allocate other
data sets using traditional JCL statements for each step.
Ensure that your JCL dispositions are properly coded to release data sets
when appropriate (for example, use FREE=CLOSE).
Delete outputs with CONDELE wherever possible.
15.9 Tuning Your System

15.9.1 Recommendations
When you are analyzing the general environment, keep these points in mind:
Ensure that VSAM and all output libraries are properly located,
maintained, and sized. Poorly tuned VSAM files can seriously degrade
performance, so:
Examine LISTCAT to analyze CA/CI splits, and reorganize if
necessary.
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, perform
better near the beginning of the string, while more stable files, such as
those in production locations, can be located near the end of the string.
Analyze how many files reside on a single pack, and how large they
are. You should split Endevor files across multiple packs, and ensure
that no other large files (such as the system catalog) share the pack.
Ensure that your file allocations are the most efficient ones for your
system.
Consider deleting and reallocating processor outputs for major system
regenerations.
Process concurrently whenever possible. For example, if you want to
recompile the entire system, specifying GEN ELEM A* K* and GEN ELEM
L* Z* instead of GEN ELEM A* Z* allows the system to process both
halves at the same time.
Consider using other products to help improve library performance. For
example, Computer Associates developers had an unload that required 90
minutes with Endevor. When they combined Endevor with two other
Computer Associates International, Inc. products, Unicenter CA-PMO and
Unicenter CA-QuickFetch, the unload took only 12 minutes. Unicenter
CA-PMO eliminates more than 90% of the directory search I/Os for
libraries and PDSs, while Unicenter CA-QuickFetch eliminates more than
90% of the fetch I/O for load modules in any managed program library.
Define VSAM MCFs in the skeleton library using DISP=OLD to eliminate
multiple opens, closes, enqueues, and dequeues.
LRECL setting for variable block files:

The output records from the compression routine CONCOMP3 can be
larger than the input records when the input files contain binary data
uploaded from other machines, or already compressed data (output from
TRSMAIN).
While it is not possible to predict the maximum increase in size of
CONCOMP3 records, we have never seen a record increased by more than
1.6 times the size of the input record. Because the size of the output record
depends on the input data, we can make predictions for specific input
records, and suggest that you use the following recommendations for
setting variable block files.
Set the block size (BLKSIZE) for variable block files to 27998, which is
half a disk 3390 track. This size allows very rapid I/O time and very
efficient space usage. The reason for this is that MVS will put as many
records as possible in the buffer defined by the BLKSIZEs and will
only write the block if the remaining space cannot hold the next
record. If a BLKSIZE of 2550 is chosen, then it will hold a maximum of
2546 bytes; however small BLKSIZEs are inefficient for disk use and
also inefficient in I/O time.
The logical record lengths (LRECLs) for variable block files should be
at least 4 less than 27998 (that is, 27994). MVS will use what it needs
and as long as the buffer allocation (LRECL'value) is big enough, it
will fit without problems or wasting space. There is no reason to
reduce the LRECL to 255, for example. For variable or variable block
files, the actual LRECL is not important. The LRECL does not define
the length of the records. The actual size is defined in the records
themselves. The LRECL defines the maximum length of any one
record. As a consequence, setting a larger LRECL and BLKSIZE for
variable block files is not a problem. As long as the LRECL is larger
than the actual record, the record will fit.
The LRECL for input records that contain binary content should have a
maximum LRECL of 13K. Then, the compression results can be twice
as big and still fit in the buffer. Since the LRECL of these uncommon
input files is usually arbitrarily chosen, we recommend keeping them
smaller than 2K, which is more efficient when Endevor does source
compares.
Appendix A. Converting Delta Formats
Appendix A. Converting Delta Formats A-1
A.1 Steps for Converting Forward to Reverse Delta

A.1.1 Procedure Summary
Conversion to reverse delta format should be planned carefully. The steps in
conversion are summarized here, then described in detail in the following
sections.
1. Analyze existing types to determine which are likely to benefit from
conversion.
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 the
necessary 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 Types

Use reverse deltas for types that:
Normally need a source output library but do not need to be backed out
(Endevor does not backout/backin base/delta libraries).
Need to be kept in standard PDS format for utilities such as Advantage
CA-File Master.
Are used exclusively on the workstation.
Types that can benefit from the reverse delta storage format include:
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 Libraries

Since the element base is the current image in reverse delta format, separate
base libraries are required for each type in a particular stage. When
reallocating your base libraries, keep the following in mind:
Plan the library structure first. Keep a record of the plan for use when
updating type definitions.
Make sure that LRECL, BLKSIZE, and RECFM parameters are appropriate
to 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 within
a system. Make sure that the new libraries map properly to stage and type
requirements.
When planning for workstation types, remember that most mainframe
compilers require LRECL=80.
A.1.4 Step 3: Resize the Delta Libraries

Resize the delta libraries to account for movement of the base component list
member to the delta library. The resizing requires space revisions to both the
file and the directory.
A.1.5 Step 4: Evaluate and Modify Processors

Evaluate your processors, keeping in mind that:
The CONWRITE step can be eliminated when using reverse deltas.
The CONWRITE step, when used, needs to be modified to take account of
revised Include libraries.
Processors can read the base library directly when reverse deltas are being
used.
A.1.6 Step 5: Run a Full Unload of Each Environment

To capture all elements, perform a full unload (BC1JUNLD) against each
environment or, optionally, by system for large installations.
A.1.7 Step 6: Adjust Type Definitions

After unloading all affected elements, change the type definitions on the Type
Definition panel for those types that you want to store in reverse delta format.
Change the:
FWD/REV DELTA field to R (reverse).
COMPRESS BASE/ENCRYPT NAME field to N (no).
SOURCE LENGTH, COMPARE FROM, and COMPARE TO fields to the
desired values.
FWD/REV delta setting in the COMPONENT LIST OPTION field
(optional).
Library definitions as necessary to reflect new base libraries and optional
changes to include and source output libraries. Use the information
recorded in Step 2.
These fields are in bold type in the Type Definition panel shown below.
CREATE

CURRENT ENV:
NEXT ENV
:
SMPLTEST
SMPLTEST
STAGE ID:
STAGE ID:
T
Q
SYSTEM:
SYSTEM:
ADMIN
ADMIN
TYPE:
TYPE:
COBOL
COBOL
DESCRIPTION
UPDATED:

BY
COMPARE FROM ===> 7
COMPARE TO ===> 72
AUTO CONSOL
===> cobol
HFS RECFM ===> NL
DATA FORMAT ===> B
FILE EXT ===>
DELTA LIBRARY
INCLUDE LIBRARY
===>
A.1.8 Step 7: Reload Inventory by System

Execute the Reload utility (BC1JRELD) by system to populate the new libraries
with your inventory.
A.1.9 Step 8: Validate the Results

Execute the Validate utility (BC1JVALD) to confirm the results.
A.2 Additional Conversion Notes
A.2 Additional Conversion Notes

A.2.1 Reverse Delta Format
Keep in mind the following when converting to reverse delta format:
Elements are stored in the new storage format after the first source
UPDATE following the conversion.
Component lists are stored in the new storage format after the first
GENERATE action is executed against the element following either a
change in an input component or a source update.
The current delta format for an element appears on panel 1 of the Element
Master display.
Source messages related to forward/reverse delta conversion are in
SMGRnnnn format.
A.3 Procedure for Converting Forward/Reverse Delta to Full-Image Delta
A.3 Procedure for Converting Forward/Reverse Delta to

Full-Image Delta
If you want to change the delta format of an existing type from
forward/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 option
may or may not be an option. The following table shows when the WITH
HISTORY option can be used for a MOVE or TRANSFER when types with
different delta formats are mapped together.
Source
Format
Target
Format
MOVE
with
history
MOVE
without
history
TRANSFER TRANSFER
with
without
history
history
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
Appendix B. Catalog Utilities B-1
B.1 Overview
B.1 Overview
Endevor uses an Element Catalog file to support long element names and to
boost performance by reducing the volume of I/O operations.
B-2 Administrator Guide
B.2 Building the Element Catalog

In moving to Endevor r7 from release 3.9 or earlier, you need to perform
several post-installation steps to prepare for implementing r7. These steps are
summarized in the following table and described in detail in the following
sections.
Step
What You Do
JCLLIB
Member/JOB
Copy all your MCF VSAM data set to

new data sets with r7 VSAM attributes.
BC1JXMCF
Copy your Package VSAM data set to a

new data set with r7 VSAM attributes.
BC1JXPCF
Define Endevor's r7 catalog VSAM data

set.
BC1JJB07
Add the ELMCATL= catalog parameter

to the C1DEFLTS table.
BC1JDEFT
Run Endevor's Catalog Build utility

against all defined Environments.
BC1JXCNV
B.2.1 Step 1: Converting Your Existing MCF VSAM Data Sets

The MCF data set's maximum record length has changed from release 3.9 and
earlier. As a result, you must redefine all your stage MCFs for all your
environments. Use member BC1JXMCF from your Endevor JCL Library to
tailor the job stream for all your MCF file conversions. This job backs up your
existing data sets to sequential files, deletes and redefines the MCF VSAM
files, then populates the records back into your newly-defined MCF file
clusters. This job is set up to handle a single environment. You need to
modify it to include all the environments defined at your site.
B.2.2 Step 2: Converting Your Existing Package VSAM Data Sets

The Package data set's maximum record length has also changed from release
3.9 and earlier. Use member BC1JXPCF from your Endevor JCL library to
tailor the job stream to do your package file conversion. This job backs up
your existing data set to a sequential file, deletes and redefines the package
file, populates the newly-defined VSAM package file with your package data.
B.2.3 Step 3: Defining the MCF Catalog Data Set

Beginning with Release 4.0, a catalog data set is used to keep track of elements
across all defined environments in your C1DEFLTS. Use member BC1JJB07
from your Endevor JCL library to define the catalog data set. You will need 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.9
release or earlier release to access Release 4.0 or r7 data. If you do, the catalog
becomes out of sync with the MCFs.
B.2.4 Step 4: Updating the C1DEFLTS Table

Update your C1DEFLTS table to identify your element catalog data set to
Endevor by using the ELMCATL parameter. Remember to compile and link it
into your site's proper authorized library.
C1DEFLTS TYPE=MAIN,
ELMCATL='CA.PROD.ELMCATL',
X
X
B.2.5 Step 5: Running the Catalog Build Utility

Run the catalog utility to populate the catalog data set with element
information. This utility should only be run during the conversion process
and it must be run against all environments defined in your C1DEFLTS table.
BC1PXCNV allows you to selectively choose the environments you want to
populate. You can run it against each environment separately or against all
environments collectively in a single step. Before you begin to use Endevor r7,
you must have run the conversion utility against all environments defined in
your C1DEFLTS table. Use member BC1JXCNV from your Endevor JCL
library to tailor the job stream to do your initial build of the element catalog.
B.3 Endevor Considerations
B.3 Endevor Considerations

Beginning with Release 4.0, the following considerations apply:
"NEXT TYPE" name can no longer differ from "this" TYPE (No type name
changes across the map are allowed.)
If long element names are used, the LRECL of the delta library must be at
least 259.
RLS or CA-Lserv implementation is highly recommended for the Endevor
Catalog data set, MCFs and the PCF (Package Control File).
Due to the key structure of the catalog, it is highly recommended that
element searches are done with an element and type specification. (The
catalog key is element name + type name.)
Endevor releases 4.0 and r7 are downwardly compatible with Endevor
R3.9, provided none of the new features have been implemented (long
element names, site symbolics, HFS pathnames, and so on).
Endevor control tables (C1DEFLTS, ENDICNFG, ENCOPTBL, etc.) are
validated at Endevor start-up time to ensure all tables are R4.0-compatible.
The Element Registration feature can be activated in WARN, CAUTION or
ERROR mode (and switched from one mode to the other at any time).
B.4 Catalog Rename Utility

The Endevor MCF Catalog Rename Utility allows you to change the catalog
name in the MCF's stage record. This utility should be run after you have
created a new catalog and have defined it to the C1DEFLTS table.
With the implementation of the Element Catalog, all MCF's have the catalog
name recorded in its stage record. The first time Endevor is invoked after
migration from a prior release, the MCF's, at open time, are updated with the
Element Catalog name. From that point on, (at open time) Endevor checks the
stage record's catalog name against the name specified in the C1DEFLTS table.
If the names are not equal, the MCF open fails. This check prevents MCF's
from belonging to more than one catalog.
The Endevor MCF Catalog Rename Utility allows you to change the catalog
name in the MCF's stage record. This utility should be run after you have
created a new Catalog and have defined it to the C1DEFLTS table.
The utility can run in two modes:
ValidateMode All environments defined in the C1DEFLTS table are
examined. A report is produced showing the current MCF catalog name
and a statement as to whether or not the name agrees or disagrees with
the C1DEFLTS table. A return code of 0 indicates all environments match
the table's definition. A return code of 4 indicates that some or all
environments are not current with the table's definition.
Update Mode All environments defined in the C1DEFLTS table are
examined, but instead of just reporting the mismatches, the utility rewrites
the stage records with the name defined from the C1DEFLTS table. A
return code of 0, under Update mode, indicates that all environments
match the table's definition. A return code of 4 indicates that some or all
of 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 the
execute statement.
B.4.1 Catalog Rename Utility Sample Report

(C) 22 Computer Associates International, Inc
Endevor
xx/xx/xx xx:xx:xx
RELEASE x.x
PAGE
1
SERIAL XXXXXX
ENDEVOR Stage Catalog Name Update/Validation UTILITY LOG

Endevor Catalog Name: CA.ENDEVOR.ELMCATL
Run Mode: VALIDATE
ENVIRONMENT
ENVIRONMENT
ENVIRONMENT
ENVIRONMENT
ENV1
ENV1
ENVA
ENVA
STAGE
STAGE
STAGE
STAGE
1
2
1
2
CATALOG
CATALOG
CATALOG
CATALOG
NAME
NAME
NAME
NAME
CA.ENDEVOR.ELMCATL..............................
CNM12I
ALL STAGES AGREE WITH THE C1DEFLTS CATALOG NAME, NO UPDATE IS NECESSARY
CNM14I
CNM17I
CNM16I
TOTAL NUMBER OF ENVIRONMENTS PROCESSED:

NUMBER OF STAGES THAT DO NOT MATCH THE NEW C1DEFLTS CATALOG NAME:
NUMBER OF STAGES THAT MATCH THE NEW C1DEFLTS CATALOG NAME:
AGREES
AGREES
AGREES
AGREES
WITH
WITH
WITH
WITH
C1DEFLTS
C1DEFLTS
C1DEFLTS
C1DEFLTS
TABLE.
TABLE.
TABLE.
TABLE.
2

4
Endevor
xx/xx/xx xx:xx:xx
RELEASE x.x
PAGE
1
SERIAL XXXXXX

Endevor Catalog Name: CA.ENDEVOR.ELMCATL
Run Mode: UPDATE
ENVIRONMENT
ENVIRONMENT
ENVIRONMENT
ENVIRONMENT
ENV1
ENV1
ENVA
ENVA
STAGE
STAGE
STAGE
STAGE
1
2
1
2
CATALOG
CATALOG
CATALOG
CATALOG
NAME
NAME
NAME
NAME
CNM1I
NO STAGE RECORDS UPDATES WERE NECESSARY, ALL SET WITH THE CURRENT CATALOG NAME
CNM14I
CNM15I
CNM16I

NUMBER OF STAGES UPDATED TO NEW C1DEFLTS CATALOG NAME:
AGREES
AGREES
AGREES
AGREES
WITH
WITH
WITH
WITH
C1DEFLTS
C1DEFLTS
C1DEFLTS
C1DEFLTS
TABLE.
TABLE.
TABLE.
TABLE.
2

4
Endevor
xx/xx/xx xx:xx:xx
RELEASE x.x
PAGE
1
SERIAL XXXXXX

Endevor Catalog Name: CA.PROD.ELMCATL
Run Mode: UPDATE
ENVIRONMENT
ENVIRONMENT
ENVIRONMENT
ENVIRONMENT
ENV1
ENV1
ENVA
ENVA
STAGE
STAGE
STAGE
STAGE
1
2
1
2
CATALOG
CATALOG
CATALOG
CATALOG
NAME
NAME
NAME
NAME
CNM11I
STAGE UPDATES WERE NECESSARY, NOT ALL AGREED WITH CATALOG NAME ENTRY IN C1DEFLTS
CNM14I
CNM15I
CNM16I

NUMBER OF STAGES UPDATED TO NEW C1DEFLTS CATALOG NAME:
DIFFERS
DIFFERS
DIFFERS
DIFFERS
FROM
FROM
FROM
FROM
C1DEFLTS
C1DEFLTS
C1DEFLTS
C1DEFLTS
TABLE.
TABLE.
TABLE.
TABLE.
2
4

B.5 Catalog Synchronization Utility

The Endevor Catalog Synchronization Utility allows you to update the element
catalog to recover differences between the element catalog and its related MCF
files.
This utility has two modes, a validate mode and an update mode. The
validate mode simply reports on the differences between the catalog and MCF
files. The update mode actually recovers the differences between the element
catalog and its related MCFs by updating the element catalog file.
Under the update mode, the utility synchronizes the element catalog and the
MCF element records in two phases.
The first phase validates MCF records against the catalog. A catalog segment is
created for any MCF record found missing from the catalog. A catalog
segment is updated with MCF element data when the associated catalog data
is found to be different.
The second phase validates the catalog to MCF in order to remove dead
segments from the catalog. All segments which do not have a MCF element
record are removed from the catalog.
Under validate mode, the utility performs the same two-phase check but does
not modify the catalog. Any differences are simply reported in the execution
log.
To select the mode, use the PARM= parameter on the JCL execution statement.
In both phases, processing is done by environment. You can specify which
environments the utility will process, or allow the environment selection to
default to all environments defined in the C1DEFLTS table.
CAUTION:
Do not use this utility to initially load the catalog file. Use job BC1JXCNV
to load the catalog file. For details, see Step 5: Running the Catalog Build
Utility in this appendix.
B.5.1 Catalog Synchronization Utility JCL

To execute the synchronization utility, use JCL member BC1JCSYN, which is
available in your site's Endevor JCLLIB data set. Edit this member to conform
to the needs of your installation before executing the job.
B.5.2 Catalog Synchronization Utility Syntax

To select which environments the utility will process, you need to edit the
BSTIPT DD JCL statement. If the DD statement is omitted or if the file is
empty (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 same
parsing rules as 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.5.3 Catalog Synchronization Utility Sample Report

The following is a sample report produced by the utility run in validate mode.
This execution shows a test Endevor system with three environments named
ENV1, ENVA, and ENVZ. In this example, the first two environments, ENV1
and ENVA, are out of synchronization with the catalog.
1

Endevor MCF Catalog Synchronization UTILITY LOG
SYNI
BEGINNING PHASE 1
SYN2I
ENVIRONMENT ENV1
MISSING CTLG SGMT:

TYPE
MISSING CTLG SGMT:
TYPE
MISSING CTLG SGMT:
TYPE
OLD
CTLG SGMT:
TYPE
OLD
CTLG SGMT:
TYPE
OLD
CTLG SGMT:
TYPE
ELEMENT
JDOHFS
ELEMENT
JDOHFS
ELEMENT
JDOHFS
ELEMENT
JDOHFS
ELEMENT
ASMPGM
ELEMENT
JDOHFS
MCF ELEMENT TO CATALOG SYNCRONIZATION STARTING

EJZZBLONGNAME2
AT ENV ENV1
SID 1 SYS SYST1 SBS SBS1
JBEANlongld5VERYLONGNAMEverylongnameVERYLONGNAMEverylongnameLAROSE
AT ENV ENV1
EJudylarose1
AT ENV ENV1
EJudylarose2
AT ENV ENV1
IA6PGM
AT ENV ENV1
OLENIC1
AT ENV ENV1
SYN3I
SYN4I
SYN5I
TOTAL # OF MISSING CTLG SGMTS FROM ENVIRON ENV1

TOTAL # OF OLD CTLG SGMTS FOUND IN ENVIRON ENV1
TOTAL # OF ELEMENTS PROCESSED FROM ENVIRON ENV1
SYN2I
ENVIRONMENT ENVA
MISSING CTLG SGMT:

TYPE
MISSING CTLG SGMT:
TYPE
3
3
12
ELEMENT TESTJO1
JCLI
AT ENV ENVA
ELEMENT SANELM1
JCLI
AT ENV ENVA
SID 2 SYS SYSTA
SBS SBSA
SID 2 SYS SYSTC
SBS SBSC
SYN3I
SYN4I
SYN5I
TOTAL # OF MISSING CTLG SGMTS FROM ENVIRON ENVA

TOTAL # OF OLD CTLG SGMTS FOUND IN ENVIRON ENVA
TOTAL # OF ELEMENTS PROCESSED FROM ENVIRON ENVA
SYN2I
ENVIRONMENT ENVZ
SYN3I
SYN4I
SYN5I
TOTAL # OF MISSING CTLG SGMTS FROM ENVIRON ENVZ

TOTAL # OF OLD CTLG SGMTS FOUND IN ENVIRON ENVZ
TOTAL # OF ELEMENTS PROCESSED FROM ENVIRON ENVZ
SYN11I
TOTAL # OF ELEMENTS PROCESSED, ALL ENVIRONMENTS:
SYNI
BEGINNING PHASE 2
SYN31I
ENVIRONMENT ENV1
:
:
:
2

5

:
:
:

1
18
CATALOG TO MCF ELEMENT SYNCRONIZATION STARTING.
ORPHAN CTLG SGMT: ELEMENT EJudylarose1

TYPE JDOHFS
AT ENV ENV1
ORPHAN CTLG SGMT: ELEMENT EJZZBLONGNAME2
:
:
:
SID 2 SYS SYST1
SBS SBS1
1NOV4 14:33:53
RELEASE 7.
PAGE
1
SERIAL B7C

1NOV4 14:34:3
RELEASE 7.
PAGE
2
SERIAL B7C
TYPE JDOHFS
AT ENV ENV1
ORPHAN CTLG SGMT: ELEMENT JBEANlongld5VERYLONGNAMEverylongnameVERYLONGNAMEverylongnameLAROSE
TYPE JDOHFS
AT ENV ENV1
SYN32I TOTAL # OF ORPHAN CTLG SGMTS
IN ENVIRON ENV1
:
3
SYN33I TOTAL CATALOG SEGMENTS PROCESSED FOR ENVIRON ENV1
:
15
SYN31I
ENVIRONMENT ENVA
ORPHAN CTLG SGMT: ELEMENT SANELM1

TYPE JCLI
AT ENV ENVA
SID 1 SYS SYSTC
ORPHAN CTLG SGMT: ELEMENT TESTJO1
TYPE JCLI
AT ENV ENVA
SID 1 SYS SYSTA
SYN32I TOTAL # OF ORPHAN CTLG SGMTS
IN ENVIRON ENVA
SYN33I TOTAL CATALOG SEGMENTS PROCESSED FOR ENVIRON ENVA
SYN31I
ENVIRONMENT ENVZ
SYN32I
SYN33I
TOTAL # OF ORPHAN CTLG SGMTS

IN ENVIRON ENVZ
TOTAL CATALOG SEGMENTS PROCESSED FOR ENVIRON ENVZ
SYN34I
TOTAL CATALOG SEGMENTS PROCESSED, ALL ENVIRONMENTS:
SBS SBSC
SBS SBSA
:
2
:
7

:
:

1
113
If the utility is executed again, but this time in update mode, the catalog is
repaired and the following log report is produced.
1

SYNI
BEGINNING PHASE 1
SYN2I
ENVIRONMENT ENV1
CREATED CTLG SGMT:

TYPE
CREATED CTLG SGMT:
TYPE
CREATED CTLG SGMT:
TYPE
UPDATED CTLG SGMT:
TYPE
UPDATED CTLG SGMT:
TYPE
UPDATED CTLG SGMT:
TYPE
ELEMENT
JDOHFS
ELEMENT
JDOHFS
ELEMENT
JDOHFS
ELEMENT
JDOHFS
ELEMENT
ASMPGM
ELEMENT
JDOHFS

EJZZBLONGNAME2
AT ENV ENV1
JBEANlongld5VERYLONGNAMEverylongnameVERYLONGNAMEverylongnameLAROSE
AT ENV ENV1
EJudylarose1
AT ENV ENV1
EJudylarose2
AT ENV ENV1
IA6PGM
AT ENV ENV1
OLENIC1
AT ENV ENV1
SYN3I
SYN4I
SYN5I
TOTAL CATALOG SEGMENTS CREATED FOR ENVIRON ENV1

TOTAL CATALOG SEGMENTS UPDATED FOR ENVIRON ENV1
TOTAL # OF ELEMENTS PROCESSED FOR ENVIRON ENV1
SYN2I
ENVIRONMENT ENVA
CREATED CTLG SGMT:

TYPE
CREATED CTLG SGMT:
TYPE
3
3
12
ELEMENT TESTJO1
JCLI
AT ENV ENVA
ELEMENT SANELM1
JCLI
AT ENV ENVA
SID 2 SYS SYSTA
SBS SBSA
SID 2 SYS SYSTC
SBS SBSC
SYN3I
SYN4I
SYN5I
TOTAL CATALOG SEGMENTS CREATED FOR ENVIRON ENVA

TOTAL CATALOG SEGMENTS UPDATED FOR ENVIRON ENVA
TOTAL # OF ELEMENTS PROCESSED FOR ENVIRON ENVA
SYN2I
ENVIRONMENT ENVZ
SYN3I
SYN4I
SYN5I
TOTAL CATALOG SEGMENTS CREATED FOR ENVIRON ENVZ

TOTAL CATALOG SEGMENTS UPDATED FOR ENVIRON ENVZ
TOTAL # OF ELEMENTS PROCESSED FOR ENVIRON ENVZ
SYN11I
SYNI
BEGINNING PHASE 2
SYN31I
ENVIRONMENT ENV1
:
:
:
2

5

:
:
:

1
18
DELETED CTLG SGMT: ELEMENT EJudylarose1

TYPE JDOHFS
AT ENV ENV1
DELETED CTLG SGMT: ELEMENT EJZZBLONGNAME2
:
:
:
SID 2 SYS SYST1
SBS SBS1
1NOV4 14:33:53
RELEASE 7.
PAGE
1
SERIAL B7C

1NOV4 14:34:3
RELEASE 7.
PAGE
2
SERIAL B7C
TYPE JDOHFS
AT ENV ENV1
DELETED CTLG SGMT: ELEMENT JBEANlongld5VERYLONGNAMEverylongnameVERYLONGNAMEverylongnameLAROSE
TYPE JDOHFS
AT ENV ENV1
SYN32I TOTAL CATALOG SEGMENTS DELETED
FOR ENVIRON ENV1
:
3
SYN33I TOTAL CATALOG SEGMENTS PROCESSED FOR ENVIRON ENV1
:
15
SYN31I
ENVIRONMENT ENVA
DELETED CTLG SGMT: ELEMENT SANELM1

TYPE JCLI
AT ENV ENVA
SID 1 SYS SYSTC
DELETED CTLG SGMT: ELEMENT TESTJO1
TYPE JCLI
AT ENV ENVA
SID 1 SYS SYSTA
SYN32I TOTAL CATALOG SEGMENTS DELETED
FOR ENVIRON ENVA
SYN33I TOTAL CATALOG SEGMENTS PROCESSED FOR ENVIRON ENVA
SYN31I
ENVIRONMENT ENVZ
SYN32I
SYN33I
TOTAL CATALOG SEGMENTS DELETED

FOR ENVIRON ENVZ
SYN34I
SBS SBSC
SBS SBSA
:
2
:
7

:
:

1
113
If the utility is execution a second time in update mode, no discrepancies

should be found.
1

SYNI
BEGINNING PHASE 1
SYN2I
ENVIRONMENT ENV1
SYN3I
SYN4I
SYN5I
TOTAL CATALOG SEGMENTS CREATED FOR ENVIRON ENV1

TOTAL CATALOG SEGMENTS UPDATED FOR ENVIRON ENV1
TOTAL # OF ELEMENTS PROCESSED FOR ENVIRON ENV1
SYN2I
ENVIRONMENT ENVA
SYN3I
SYN4I
SYN5I
TOTAL CATALOG SEGMENTS CREATED FOR ENVIRON ENVA

TOTAL CATALOG SEGMENTS UPDATED FOR ENVIRON ENVA
TOTAL # OF ELEMENTS PROCESSED FOR ENVIRON ENVA
SYN2I
ENVIRONMENT ENVZ
SYN3I
SYN4I
SYN5I
TOTAL CATALOG SEGMENTS CREATED FOR ENVIRON ENVZ

TOTAL CATALOG SEGMENTS UPDATED FOR ENVIRON ENVZ
TOTAL # OF ELEMENTS PROCESSED FOR ENVIRON ENVZ
SYN11I
SYNI
BEGINNING PHASE 2
SYN31I
ENVIRONMENT ENV1
SYN32I
SYN33I

FOR ENVIRON ENV1
TOTAL CATALOG SEGMENTS PROCESSED FOR ENVIRON ENV1
SYN31I
ENVIRONMENT ENVA
SYN32I
SYN33I

FOR ENVIRON ENVA
TOTAL CATALOG SEGMENTS PROCESSED FOR ENVIRON ENVA
SYN31I
ENVIRONMENT ENVZ
SYN32I
SYN33I

FOR ENVIRON ENVZ
SYN34I

:
:
:

12

:
:
:

5

:
:
:

1
18

:
:

12

:
:

5

:
:

1
18
1NOV4 14:36:29
RELEASE 7.
PAGE
1
SERIAL B7C
Appendix C. Interfacing Endevor with CA Common

Services
Appendix C. Interfacing Endevor with CA Common Services C-1
C.1 Overview
C.1 Overview
With Endevor, you can trap messages issued by Endevor user exits and
processor programs and display them on the CA Common Services (CCS)
Event Console. Once alerted to the event, the Event Console administrator can
respond appropriately.
For example, with this facility you can notify a Endevor administrator when a
Endevor package has been denied by one of the package approvers or if an
attempt to move an element into the production environment fails.
C-2 Administrator Guide
C.2 Formatting Endevor Messages
C.2 Formatting Endevor Messages

Lets look at the following message to understand how events issued from
Endevor can be used by CCS Event Manager. Let's assume this message
appears 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 the
non-bold part was added by CCS Event Management routines. Let's assume
this 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 Endevor messages. When it encounters
this message id, it routes the messages to a secondary console that logs and
prints each message for later review.
It is the responsibility of the Endevor administrator to structure the contents of
their messages in a way that allows the message to be trapped and forwarded
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 the
following information:
A unique message identifier
A severity code
The date and time
Endevor inventory location information
A detailed description of the error
You should also try to delimit message components with a space or a standard
character to simplify forming events and rules.
C.3 How the Interface Works
C.3 How the Interface Works

The illustration below shows how Endevor sends messages to the CCS Event
Manager. From Endevor, you can code a user exit or a Endevor processor
program and REXX procedure to invoke the Endevor Interface, which in turn,
traps message and sends events to the An IP address table determines which
Event Console receives the event.
The CCS Event Manager takes the free-format 102-byte message and adds
control and system information before routing the entire message composite to
the indicated consoles. Once the message is received at each console, CCS
Event Management detects messages based upon string content and takes
action using the message action facilities of Event Management.
Refer to the CCS tutorials and documentation for instructions on completing
these tasks.
Procedures for calling the interface from a user exit or from a processor are
described below, followed by information about creating the CCS IP address
table.
C.4 Calling the Interface From a User Exit
C.4 Calling the Interface From a User Exit

One method of calling the Endevor Interface is to code a Endevor user exit
program. The user exit program must call the user exit interface assembler
program, BC1PTRPO.
The BC1PTRPO user exit interface program requires two parameters:
Message A 102 byte message field which is passed 'as-is' to the Event
Console.
Result-area An 80-byte field into which BC1PTRPO returns the result of
the Event submission. If the Event submission is successful, it contains
"OK" as the first two characters, padded with spaces. Otherwise, it
contains the reason for the Event submission failure.
The user exit must build the message and interrogate the result area. Writing
user exits assumes you have a working knowledge of Endevor user exit
architecture. A sample user exit is delivered as member XIT3MSG, in the
iprfx.iqual.SOURCE library. For more information on user exits, refer to Exits
Guide.
C.5 Calling the Interface From a Processor

Another way of calling the Endevor Interface utilizes a Endevor processor
which executes a REXX procedure. The REXX procedure must call the REXX
procedure interface program, BC1PTRAP.
The BC1PTRAP REXX procedure interface program is an assembler program
which is called with one parameter and returns a result message to the REXX
procedure:
Message A 102 byte message field which is passed 'as-is' to the Event
Console.
Result-area A field where BC1PTRAP returns the result of the Event
submission. If the Event submission is successful, it contains "*-ok" as the
first four characters, padded with spaces. Otherwise, it contains the reason
for 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 below.
C.5.1 Sample Endevor Processor Fragment

To call the Endevor Interface from a Endevor processor, you should refer to
the sample processor fragment below in combination with the REXX procedure
sample, ENFSAMP, that follows.
//
// CREATE TEMPORARY INPUT FILE TO SEND A MESSAGE

//
//MSGBLD
EXEC PGM=IEBGENER
//SYSPRINT DD
SYSOUT=
//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=IKJEFT1,
//
COND=((5,NE,SMSGFG),(5,LT)),MAXRC=7
//SYSTSPRT DD DSN=&&PARMLIST,DISP=(OLD,PASS)
//SYSTSIN
DD DSN=&&TEMPMSG,DISP=OLD
C.5.2 REXX Procedure Sample

The REXX procedure, ENFSAMP, passes a message to the Endevor REXX
interface program, BC1PTRAP. Any error conditions are passed back to the
REXX procedure using standard REXX WORD return protocol.
The following REXX procedure corresponds to the processor fragment above.
/ 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 14 to account for the enclosing quotes/
message= msgid||" A "||prm1||" OF "||prm2||" FAILED"
message=LEFT(message,12)
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.6 Setting Up the IP Addresses of Event Consoles

Once the Endevor Interface receives the message events from either the user
exit or Endevor processor, it needs to know where to direct the events. The
BC1TIPAD macro is used to specify the IP addresses of Event Consoles. There
are three types of BC1TIPAD macros, which are distinguished by the keyword
parameter IPVAL:
IPVAL=START is required as the first macro. It indicates the beginning of
the table.
IPVAL=IP address identifies the address of an Event Console to which the
messages are routed. You can code as many of these parameters as you
need; at least one is required.
IPVAL=END is required as the last macro. It indicates the end of the
table.
JCL to assemble and link-edit this table is located as member BC1JIPAD in the
iprfx.iqual.JCLLIB library. This member contains an embedded BC1TIPAD
macro source. After editing the IP address macros, copy your JOBCARD
member to the beginning of BC1JIPAD, and then submit the job for execution.
Below is the file containing the BC1JIPAD member delivered on the installation
tape. Step 1 assembles the macro and passes the assembled IP address table to
Step 2. Step 2 link-edits the IP address table, then stores it in the AUTHLIB as
member BC1TIPAD.
/(JOBCARD)
//-----------------------------------------------------------------
// COPYRIGHT (C) 22 COMPUTER ASSOCIATES INTERNATIONAL, INC.

//

// 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=496K,
//
//SYSLIB
//SYSLIN
DD DSN=&&SYSLIN,
//
UNIT=tdisk,
//
SPACE=(TRK,(3,5)),
//
//
//SYSPUNCH DD DUMMY
//SYSUT1
//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=248K,COND=(,NE),
//
PARM='LIST,NCAL,XREF,LET,RENT,REUS'
//SYSLIN
DD DSN=&&SYSLIN,
//
//SYSLMOD DD DISP=SHR,DSN=uprfx.uqual.AUTHLIBHLIB(BC1TIPAD)
//SYSUT1
Appendix D. Long Name and HFS File Support
Appendix D. Long Name and HFS File Support D-1
D.1 Long Name and HFS Support Overview

Long name support allows Endevor to support:
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 type
definitions
Processor symbolics for long name elements and HFS directories
HFS path and file name support for the CONWRITE and CONDELE
utilities
D.1.1 HFS Path Name

The HFS path name can be a maximum of 768 characters long and contain
these characters:
Uppercase letters
Lowercase letters
Numbers
National characters
Slash (/)
Plus (+)
Hyphen (-)
Period (.)
D.1.2 HFS Files

A file name can be 255 characters long. To be portable, the file name should
use only the characters in the POSIX portable file name character set:
Uppercase or lowercase A to Z
Numbers 0 to 9
Period (.)
Underscore (_)
Hyphen (-)
File name rules:
Cannot contain nulls or / (slash) characters
Does not support double- byte characters
D-2 Administrator Guide
Shells are case-sensitive, and distinguish between upper and lower case
characters, therefore FILE1 and file1 are not the same
File names can include the following:
Suffixes
An extension, consisting of a period (.) and several characters, to
indicate 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 strongly
recommended, it allows you to execute a single command against multiple
files.
Warning: Double-byte characters in a file name can cause problems, they are
treated 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 Names

Element names can be 255 characters long, containing these characters:
Uppercase letters
Lowercase letters
Numbers
National characters
Period(.)
Hyphen (-)
Underscore(_)
D.1.4 Long Name Support and Endevor Interfaces

Long name support varies for the Endevor interfaces. The following table
explains these differences:
Interface
Long Name and HFS support
ISPF
No support for actions involving long name elements or path

names.
Quick Edit
Element names greater than 10 characters are truncated in

lists. 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. If
there are multiple long name elements and the first
five characters are identical, ISPF displays a single
entry.
HFS path names longer than 44 characters are truncated in
type definitions and on the element master display screen.
The truncated format consists of:
Batch (SCL)
API
Enterprise
Workbench
Left bracket ({)

The first 39 characters of the path name
An ellipsis (...)
Right bracket (})
Element names can be 255 characters long, containing

mixed-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 these 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

D.2.1 Adding and Retrieving Long Name Elements
These "file types" are used to add elements to Endevor or retrieve elements
from Endevor:
DSN files 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 Endevor and saved as a DSN member or as a
file in the HFS directory. There is no relationship between the element name
and the member name/file name. The element name's characteristics limit
which file type can be used as the target of the retrieve action.
Element Name
Characteristics
HFS
DSN
Long 1 alphanumeric,

mixed case and @, $, #, ., -, _
Yes
No
Short 2 alphanumeric,

mixed case and @, $, #, ., -, _
Yes
No

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 Elements

The following table summarizes the supported storage definitions and any
limitations for elements in Endevor.
Element Name
Characteristics
HFS
Base
DSN
Base
HFS
Source
Output
DSN
Source
Output

mixed case and @, $, #, ., -, _
Yes
Forwarddelta
only
Yes
No

mixed case and @, $, #, ., -, _
Yes
Forwarddelta
only
Yes
No

Yes
Yes
Yes
Yes
Note:
D.2.3 Displaying Element Information

Element lists behave differently in the various interfaces. ISPF and Quick Edit
lists use brackets to designate long name elements and short name elements
with lower case characters. Enterprise Workbench displays the full element
name.
Element Name
Characteristics
Sample Element
Name
ISPF/Quick Edit
Enterprise
Workbench

mixed case and @, $, #, ., -, _
abcdefghijklm
{abcde...} 3
abcdefghijklm

mixed case and @, $, #, ., -, _
LoNgNaMe
{LoNgNaMe} 3
LoNgNaMe

ELEMENT1
ELEMENT1
ELEMENT1
Note:
3: Element information is not available from these lists, it is only accessible from the Enterprise
Workbench. If there are multiple long name elements and the first five characters are identical, ISPF
displays a single entry.

D.3.1 HFS Directories and Endevor Libraries
With UNIX System Services (USS) HFS File support some Endevor libraries
can be located in HFS partitions. Currently, the only supported libraries are:
Base
Source output
Include
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
Endevor listing libraries
Yes
No
Include libraries
Yes
Yes
Notes:
1. Processors can write outputs to HFS directories.
2. Ensure that the maximum record size associated with the HFS file can be
accommodated by the delta library specified on the type definition.
D.3.2 Using Site Symbolics for Type Definitions

When designating HFS directories as base, source output, or include libraries
in type definitions, you must use site symbolics. When viewing the type
definition in ISPF, symbolics are displayed for the longer paths. As with
Endevor or user symbolics, the site symbolics are resolved at runtime.
D.3.3 HFS Directories and Endevor Actions

Endevor supports HFS directories for add/update and retrieve actions initiated
in batch (SCL) or from Enterprise Workbench. The table below summarizes
the actions supported by HFS locations.
Action
Fields
HFS Support
Add/Update
'from'
Retrieve
'to'
Archive
'to'
Restore
'from'
Transfer
'from archive' and

'to archive'
Unload
'to'
Reload
'from'
D.3.4 HFS Files and Endevor Actions

Endevor allows you to work with HFS files, long name elements and short
names containing lower case characters using the Enterprise Workbench or the
batch interface.
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 > 44
characters
Master display,
'Added from'
Displays full path
N/A
Brackets if > 44
characters
Add\Update,
'Add from'
Input allowed
Input not allowed
Full HFS path and file

name
Retrieve,
'Retrieve to'
Input allowed
Input not allowed
Full HFS path and file

name
Type definition
Input allowed
Base libraries
Source output libraries
Include libraries
Input not allowed
Using site symbolics
Type display
Displays symbolics
N/A
Displays full path
Note: N/A - Not applicable
D.4 HFS RECFM Field in Type Definition Panel
D.4 HFS RECFM Field in Type Definition Panel

Listed below is information on the HFS RECFM field. This field is located on
the Type Definition panel.
CREATE

CURRENT ENV:
NEXT ENV
:
SMPLTEST
SMPLTEST
STAGE ID:
STAGE ID:
T
Q
SYSTEM:
SYSTEM:
ADMIN
ADMIN
TYPE:
TYPE:
COBOL
COBOL
DESCRIPTION
UPDATED:

BY
COMPARE FROM ===> 7
COMPARE TO ===> 72
AUTO CONSOL
===> cobol
HFS RECFM ===> NL
DATA FORMAT ===> B
FILE EXT ===>
DELTA LIBRARY
INCLUDE LIBRARY
===>
D.4.1 Parameters
HFS RECFM
USS/HFS files are data streams. The HFS RECFM field specifies a record
delimiter used to emulate records. To emulate records, there must be a
record delimiter. This is the purpose of the HFS RECFM field. Record
delimiters and their HFS delimiter type are:
COMP Variable length records compressed by 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 the
RDW.
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 these 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 following
considerations in mind:
The delta PDS record format must be variable blocked.
The delta library record length and the type definition source length
can be any value (259, 6024, 27984) as long as the maximum delta
record length is about 2 times the source length. However, a value of
27,984 is recommended.
For example,
DCB=(DSORG=PO,RECFM=VB,LRECL=27984,BLKSIZE=)
3. Type definitionDefine the binary element type to include the following
element options:
Set the Fwd/Rev/Img Delta field to I. The delta type should be full
image. This suppresses the compare logic. Each update will cause the
entire 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 of
13,992.
Set the HFS RECFM field to F.
Set the Data Format field to B, for binary. If left blank, the value
defaults 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 type
when you are adding from or retrieving to a local file directory using
AllFusion CM Enterprise Workbench.
Appendix E. Working with Binary Files E-1
For example, the following sample Type Definition panel shows how you
can define a DOC file type.
DISPLAY ---------------------COMMAND ===>

CURRENT ENV:
NEXT
ENV:
I4
I4
TYPE DEFINITION
STAGE ID:
STAGE ID:
1
2
SYSTEM:
SYSTEM:
--------------------NDVRMVS
NDVRMVS
TYPE:
TYPE:
HFSFB
HFSFB
DESCRIPTION:
UPDATED:
Binary Data with delta lrecl of 13,992

29MAR4 11:47 BY XAHFS1
----------------- 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
LVLS TO CONSOL:
5
DATA FORMAT: B
FILE EXT: doc
------------- COMPONENT LIST OPTIONS ---------------FWD/REV DELTA:
F (F/R) AUTO CONSOL: Y (Y/N)
CONSOL AT LVL:
96
LVLS TO CONSOL:
5
-------------------LIBRARIES --------------------BASE/IMAGE LIBRARY:
&#HFS8I1
DELTA LIBRARY:
BST.HFSVB.DELTA
INCLUDE LIBRARY:
SOURCE O/P LIBRARY:
E-2 Administrator Guide
Appendix F. Email Notification
Appendix F. Email Notification F-1
F.1 ESMTPTBL
F.1 ESMTPTBL
Email notification within Endevor is enabled by creating the mainframe ID and
email ID table, ESMTPTBL. This table maps mainframe user IDs to email IDs
or group names. When an email notification event occurs, the invoked
program scans the ESMTPTBL table for an appropriate match. The program
searches the table for a matching mainframe ID. If a match is found, an email
addressed to the associated email ID is sent. If no match is found, no email is
sent.
F-2 Administrator Guide

The following components are provided as part of the Email Notification
Facility.
Component
Description
$ESMTP
Macro that builds a table (ESMTPTBL) that maps mainframe IDs to email
IDs.
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.3 $ESMTP Macro
F.3 $ESMTP Macro

A new macro, $ESMTP, builds the mainframe ID and email ID table,
ESMTPTBL. The macro has a section for global information and a section for
each mainframe user ID.
The JCL to assemble and link this macro is located in iprfx.iqual.jcllib. The
resulting load module, ESMTPTBL, must reside in the Endevor authorized
library (uprfx.uqual or iprfx.iqual.AUTHLIB).
The global information section includes the following fields.
Item
Description
Host Name
NJE node name of the OS/390 system where SMTP is running.
Default Domain
Domain name to be used in email addresses. You can override this field in
the mainframe ID section.
Default URL
URL where Enterprise Workbench is running. You can override this field
in the mainframe ID section.
SMTP Task Name
The name of the SMTP address space. The default is SMTP and is rarely
subject to change.
SMTP SYSOUT CLASS
The SYSOUT CLASS associated with the SMTP task. The default is B and
is rarely subject to change.
The mainframe ID/email ID section includes the following fields.
Item
Description
Host Name
NJE node name of the OS/390 system where SMTP is running.
Mainframe ID
The mainframe user ID or package approver group name. This field can
contain up to 16 character.
Email ID
The portion of the email ID that preceeds the @. This field size is
unlimited.
Domain
The portion of the email ID that follows the @. If not specified, the global
default domain is used. This parameter supports an environment where
email IDs might be defined in multiple domains.
URL
The URL where Enterprise Workbench is running. If not specified, the

global default URL is used. This parameter enables you to point users to
different implementations of Enterprise Workbench.
F.4 Sample ESMTPTBL
F.4 Sample ESMTPTBL

FIRST INVOCATION - DEFINE "GLOBAL" VALUES
---------------------------------------------------------------------
$ESMTP HOSTNAME=USILDAMA,DFTDOMAIN=ca.com,
X
DFTURL='http://endevor/ccm12/webpages/login.jsp'

SUBSEQUENT INVOCATIONS - DEFINE APPROVER GROUP NAME OR USERIDS
---------------------------------------------------------------------
$ESMTP MFID=APPRV1,EMAILID=Approver1
$ESMTP MFID=APPRV3,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
F.5 BC1JSMTP
F.5 BC1JSMTP
//(JOBCARD)
//-------------------------------------------------------------------
//

//

//

// NAME: BC1JSMTP

//

// PURPOSE: BC1JSMTP IS USED TO ASSEMBLE AND LINK EDIT THE ENDEVOR

//
EMAIL USERID / EMAIL ID TABLE. THE TABLE IS NAMED

//
ESMTPTBL.

//

//-------------------------------------------------------------------
// STEP 1: ASSEMBLE THE ENDEVOR EMAIL MAINFRAME ID / EMAIL ID TABLE
//-------------------------------------------------------------------
//ASM
EXEC PGM=ASMA9,
//
REGION=372K,
//
//SYSLIB
DD DISP=SHR,DSN=IPRFX.IQUAL.SOURCE
//SYSLIN
DD DSN=&&SYSLIN,
//
UNIT=TDISK,
//
SPACE=(TRK,(3,5)),
//
//
//SYSPUNCH DD DUMMY
//SYSUT1
DD UNIT=TDISK,SPACE=(TRK,(5,15))
//SYSIN
DD
ESMTPTBL TITLE 'ENDEVOR SMTP EMAIL TABLE'


NAME:
ESMTPTBL

DESCRIPTION: ENDEVOR SMTP EMAIL ADDRESS TABLE.

FUNCTION:
THIS TABLE CONTAINS MAINFRAME USER ID TO EMAIL

ID INFORMATION.

INSTRUCTIONS:

1. TAILOR THIS TABLE AS NEEDED.

hname = SMTP HOST NAME

dftdmn = default EMAIL DOMAIN NAME

dfturl = URL FOR ECCM OR ENDEVOR WEBSTATION SERVER

usrid = TSO userid of approver or approver grp name

emailaddr = e-mail address of the user

usrdname = domain name if different from default

usrurl = url for eccm or webstation if different

from the default

2. ASSEMBLE AND LINKEDIT THE TABLE USING THE MEMBER

BC1JSMTP CONTAINED IN THE EXAMPLE SOURCE LIBRARY.

F.5 BC1JSMTP
ASSEMBLY RETURN CODES:

- NORMAL

12 - PARAMETER ERROR, TABLE SHOULD NOT BE LINKED.

CONTACT ENDEVOR SUPPORT.

FIRST INVOCATION - DEFINE "GLOBAL" VALUES
---------------------------------------------------------------------
$ESMTP HOSTNAME=hname,DFTDOMAIN=dftdmn,
X
DFTURL='http://defturl'

SUBSEQUENT INVOCATIONS - DEFINE APPROVER GROUP NAME OR USERIDS
---------------------------------------------------------------------
$ESMTP MFID=usrid,EMAILID=emailaddr
$ESMTP MFID=usrid,EMAILID=emailaddr,
X
DOMAIN=usrdname,URL='http://usrurl'

LAST INVOCATION - END THE TABLE GENERATION
---------------------------------------------------------------------
$ESMTP CALL=END
//-------------------------------------------------------------------
// 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.

//-------------------------------------------------------------------
//LINK
EXEC PGM=IEWL,
//
REGION=248K,
//
PARM='LIST,NCAL,XREF,LET,RENT,REUS',
//
COND=(,NE)
//SYSLIN
DD DSN=&&SYSLIN,
//
//SYSLMOD DD DISP=SHR,DSN=UPRFX.UQUAL.AUTHLIB(ESMTPTBL)
//SYSUT1
DD UNIT=TDISK,SPACE=(TRK,(5,15))
F.5 BC1JSMTP
Index
Archive Action 1-18
Attributes
LOG 15-12
tuning 15-15
Audit stamps 1-21
Special Characters
$CIPOREC 8-16
$SMFBKDS 9-13
$SMFHDDS 9-5
$SMFREC1 9-7
$SMFREC2 9-11
$SMFREC4 9-20
++CONTROL password interface
Base libraries
about 1-15
allocating A-3
resizing A-3
symbolics 3-43
Base members 15-7
BC1JRELD A-4
BC1JUNLD A-3
BC1JVALD A-5
BC1PNCPY 15-9
BC1PTRAP REXX procedure
BC1PTRPO C-5
Blocks
about 9-2
action-specific 9-13, 9-20
Buffer pool 15-11
6-30
Action
availability 1-18
blocks 9-3
by job function 1-19
Display 1-18
Prompt panel 8-5
Action Records
blocks 9-4, 9-11, 9-13, 9-20
SMF 9-3
Add Action
CCIDs updates 8-6
function 1-18
specifying for elements 8-7
Adding options to User Options Menu
Addresses IP C-8
Adjusting type definitions A-4
AllFusion CA-Librarian 15-8
AllFusion CA-Panvalet 15-8
AllFusion CA-Panvalet Interface
access module, link-editing 6-28
setting parameters 6-29
Allocating base libraries A-3
Alternate Defaults Table
creating 14-3
example 14-3
Alternate ID support 6-39
Analyzing types for deltas A-2
11-4
C-6
C1DEFLT macros 4-2

C1DEFLTs
adding the element catalog B-4
CA Common Services Event Manager (CCS)
CA-AllFusion CA-Librarian Interface
customizing 6-34
defining Endevor types 6-37
CA-L-Serv 15-10
Calling the Endevor interface C-5
Capturing elements A-3
CCID definition data set
adding to Defaults Table 6-25
C-3
Index X-1
CCID definition data set (continued)

allocating 6-24
initializing 6-24
installation steps 6-24
CCIDs
about 8-2
Add Action updates 8-6
data set sample definition 8-17
definition data set 8-15, 8-16
Delete Action updates 8-11
Endevor's impact on actions 8-12
fields 8-3
Generate Action updates 8-8
ISPF Text Editor 8-16
Move Action updates 8-9
predefining 8-14
requiring 8-4
Restore Action updates 8-12
Retrieve Action updates 8-8
sample definition 8-17
Transfer Action updates 8-10
updating fields 8-6
validation 8-14
Change Control Identifiers see CCIDs
Changing name of data set for a system
Classifications for Inventory maps 4-3
Classifying elements 1-13
Cloning 3-25
Commands 1-18
Comments see CCIDs
Communication Server 15-11
Components of logical structure 1-6
Consolidation trigger level 15-5
Conventions for naming types 3-41
Converging
routes 4-5
systems in a route 4-6
Conversion
catalog build B-4
MCF B-3
package data sets B-3
Conversions
deltas A-2, A-6
forward/reverse to full-image A-7
CONWRITE utility
about 15-3
modifying processors A-3
tuning processors 15-14
Copy Action 1-18
X-2 Administrator Guide
Copyback 8-9
Copying system, subsystems and types
Creating
CCID definition data set 8-15
executable forms of elements 1-20
Cycle, software life 1-3
3-49
Data
sets
security 1-22
Data blocks
about 9-2
security 9-7
Data sets
CCIDs definition 8-15
definitions for type 3-49
field definition 8-17
package 1-15
sample definition 8-17
Type panel 3-50
Type Request panel 3-49
Defaults Table
about 1-2
assembling 13-3
editing 13-2
establishing routes 4-2
Defining
environments 1-8
maps 4-2
new systems 3-18
processing sequence 3-45
subsystems 1-11, 3-28
symbolics 3-43
systems 1-10, 3-18
types 1-12, 3-31, 3-45
Definition file 8-15
Delete
processors 1-20
Delete Action
CCIDs updates 8-11
function 1-18
Deltas
analyzing types A-2
consolidation trigger level 15-5
conversions A-2, A-7
element consolidation 15-5
formats 15-3
forward 3-43
full-image 3-43
3-25
Deltas (continued)
libraries 1-15
library types 15-7
number of levels to retain 15-5
resizing libraries A-3
reverse 3-42
storage formats 3-42
symbolics 3-43
Display
environment information 3-52
Site Information panel 3-7
Stage Information panel 3-16
DSECTs
$SMFBKDS 9-13
$SMFHDDS 9-5
$SMFREC1 9-7
$SMFREC2 9-11
$SMFREC4 9-20
about 9-5
SMF security records 9-2
Duplicate element names
processor group 5-5
subsystem level 5-3
system level 5-3
duplicate elements 5-2
Duplicating system, subsystems and types
Editor 8-16
Element Catalog 1-15
build B-4
building B-3
C1DEFLTs B-4
MCF conversion B-3
Element Registration 5-25-7
Elements
capturing A-3
classifying 1-13
creating executable forms 1-20
definition of 1-7
delta consolidation 15-5
querying for 1-14
specifying an Add Action 8-7
storage formats 3-42
unload A-3
working with 1-18
Email notification
ESMTPTBL F-2
ENCOPTBL
3-25
Endevor
Actions 1-18
calling the Interface C-5
definition data set 8-15
ESI 1-22
impact on fields 8-12
inventory structure
classifying elements 1-13
setting up 1-7
LIB 15-7
library list 1-15
messages C-4
security 1-22, 9-1
updating CCIDs fields 8-6
ENFSAMP C-6
ENUXSITE 14-2
See also Alternate Defaults Table
Environment
defining 1-8
definition of 1-6
displaying information 3-52
Information panel 3-52
mapping 15-6
options menu 3-4
ESI 1-22
Establishing routes in the Defaults Table 4-2
Evaluating processors A-3
Event Manager for C-3
Event Manager for CA Common Services
(CCS) C-3
Execute
BC1JRELD A-4
BC1JVALD A-5
forms of elements 1-20
Exit program for Endevor users C-5
External Security Interface (Endevor ESI) 1-22
Facility native security 1-22

Fields
$SMFHDDS DSECT 9-6
$SMFREC1 DSECT 9-8
$SMFREC2 DSECT 9-12
action block 9-169-20
CCIDs 8-3
Endevor actions impact on 8-12
Environment Information panel 3-52
Site Information panel 3-8
Stage Information panel 3-16
Index X-3
Fields (continued)
Subsystem Definition 3-29
System Definition panel 3-20
System Definition panel for cloning 3-26
Type Definition panel 3-34
Type Processing Sequence panel 3-47
updating CCIDs 8-6
File definition 8-15
File processing for VSAM 15-10
Footprints 1-21
Formats for deltas 15-3
Formatting messages C-3
Forward deltas
about 3-43, 15-3
conversion to full-image A-7
conversion to reverse A-2
Full-image deltas
about 3-43, 15-4
conversion from forward/reverse A-7
Functions
for jobs 1-19
for menus 11-2
Generate
processors 1-20
Generate Action
CCIDs updates 8-8
function 1-18
GLobal Type Sequencing
6-44
Header blocks
about 9-2
SMF 9-5
History
Move Action 8-9
Transfer Action 8-10
WITH option for deltas
A-7
Identifying systems 3-5

Impact of Endevor on fields 8-12
Implementing Record Level Sharing 15-13
Include libraries 1-17
Interfaces
++CONTROL password interface 6-30
AllFusion CA-Panvalet Interface 6-28
CA-AllFusion CA-Librarian Interface 6-33
Interfaces (continued)
SMF interface 6-26
Inventory map classifications 4-3
Inventory structure
components 1-6
querying 1-14
setting up 1-7
IP addresses C-8
IPVAL C-8
ISPF
panels 11-5
Text Editor 8-16
ISPF dialog options configuration table
assembling and link-editing 12-13
default configuration table 12-3
dialog options fields 12-5
overview 12-1
Levels number of to retain 15-5

LIB 15-7
Libraries
about 1-15
Base
allocating A-3
resizing A-3
symbolics 3-43
Deltas
resizing A-3
types 15-7
include 1-17
list 1-15
types 15-7
Life cycle of software 1-3
List Action 1-18
Listing libraries 1-17
LOG attributes 15-12
Logical structure
components 1-6
querying 1-14
setting up 1-7
Macros
$CIPOREC 8-16
for BC1TIPAD C-8
Managing actions 1-20

Mapping multiple environments 15-6
Maps 4-14-4
Master Control File (MCF)
CA-L-Serv 15-10
definition of 1-15
MCF Catalog
convert B-3
defining B-4
rename utility B-6
update B-6
utility B-6
validate B-6
Menus
environment options 3-4
functions 11-2
modifying User Options 11-4
User Option 11-2
Messages formatting C-3
Modifying
processors A-3
User Options Menu 11-4
Monitoring CA-L-Serv's performance 15-10
Move
processors 1-20
Move Action
CCIDs updates 8-9
function 1-18
with history 8-10
without history 8-9
Multiple mapping environments 15-6
Naming conventions 3-41

Native security facility 1-22
New systems defining 3-18
Number of levels to retain 15-5
Optional feature table

See also ENCOPTBL
activating source entries 6-2
ENCOPTBL 6-2
source 6-2
Options
environment menu 3-4
User Menu 11-2
Output
libraries 1-17
Output (continued)
management 1-20
Output Type
element registration
5-7
Package data set 1-15

Package data sets
conversion B-3
Packages 1-21
Panels
about 3-2
Action Prompt 8-5
Environment Information 3-52
ISPF 11-5
Request 3-5
Selection List 3-5
Site Information 3-7
Stage Information 3-16
Subsystem
Definition 3-29
Request 3-28
System
Definition 3-19, 3-26
Request 3-18
Type
Data Set Request 3-49
Data Sets 3-50
Definition 3-33
Processing Sequence 3-46
Request 3-31
Sequence Request 3-45
User Options Menu 11-3
using to define a map 4-3
Parameters
consolidation trigger level 15-5
for BC1PTRAP C-6
for BC1PTRPO C-5
IPVAL C-8
number of levels to consolidate 15-5
RECBUFFSIZE 15-10
Parmlib data set 6-43
Partitioned data set (PDS) 1-7
Password
++CONTROL password interface 6-30
PDS 1-7, 15-7
PDS/E 15-7
Point in Time Recovery 15-10
Predefining CCIDs 8-14
Index X-5
Print Action 1-19

Procedure
adding options to User Options Menu 11-4
BC1PTRAP REXX C-6
changing name of data set for a system 3-49
cloning inventory definitions 3-25
converting forward to reverse delta A-2
creating CCID definition data set 8-15
defining
new system 3-18
subsystem 3-28
type processing sequence 3-45
types 3-32
removing options from User Options Menu 11-4
requiring CCIDs for a system 8-4
Processing
backout 15-3
sequence 3-45
Processor Group
duplicate elements 5-5
element registration 5-5, 5-7
output type 5-7
Processors
calling Endevor Interface C-6
evaluating A-3
libraries 1-15
modifying A-3
tuning 15-14
types of 1-20
Programs
BC1PTRAP C-6
BC1PTRPO C-5
user exit C-5
Providing stage id 4-2
Querying the inventory structure
1-14
RECBUFFSIZE 15-10
Record level sharing (RLS) 15-12
Records
data block security 9-7
SMF 9-2
Recovery Point in Time 15-10
Reload utility A-4
Removing options from User Options Menu
Reporting 1-20
11-4
Request panel 3-5

Requiring CCIDs for a system 8-4
Resizing base libraries A-3
Restore Action
CCIDs updates 8-12
function 1-19
Retain number of levels to 15-5
Retrieve Action
CCIDs updates 8-8
function 1-19
Reverse deltas
about 3-42, 15-3
conversion from forward A-2, A-6
conversion to full-image A-7
REXX procedure C-6
RLS 15-12
Routes
establishing in the Defaults Table 4-2
types of 4-4
Samples
CCID definition data set 8-17
REXX procedure C-6
Security
about 1-22
native 1-22
record data block 9-7
SMF 9-1
Selection List panel 3-5
Sequence processing 3-45
Sequential data set 8-16
Set
package data 1-15
Setting up
inventory structure 1-7
IP addresses C-8
Signin Action 1-19
Site Information panel
display 3-7
fields 3-83-15
Site-defined Symbolics 6-41
SMF
about 9-1
Action Records 9-3
header block 9-5
security records 9-2
SMF interface
TYPE=ENVRNMNT parameters
TYPE=MAIN parameters 6-26
6-27
Software life cycle 1-3

Source
management 1-20
output libraries 1-17
Specifying an Add Action for elements
Stage
component 1-6
ID 4-2
Information panel 3-16
Stamps, audit 1-21
Stand-alone routes 4-4
Storage 3-42
Structure Endevor inventory
about 1-6
querying 1-14
setting up 1-7
Structure, Endevor inventory
using 1-7
Subsystem
duplicate element names 5-3
element registration 5-3
Subsystems
cloning definitions 3-25
defining 1-11
definition of 1-6
Definition panel 3-29
Request panel 3-28
Suggested naming standards 3-41
Symbolics 3-43
System
converging within a route 4-6
defining 1-10, 3-18
definition of 1-6
duplicate element names 5-3
element registration 5-3
identifying 3-5
requiring CCIDs for 8-4
tuning 15-15
System Definition 5-3, 5-4, 5-5, 5-6
SYS/SBS Reg. Sev
System Definition panel
cloning 3-26
fields 3-203-24
using 3-19
System Management Facilities
See SMF interface
System Request panel 3-18
8-7
Table Defaults 1-2, 4-2

Text editor 8-16
Transfer Action
CCIDs updates 8-10
function 1-19
with history 8-11
without history 8-10
Tuning
processors 15-14
system 15-15
Type
adjust definitions A-4
Data Set Request panel 3-49
Data Sets panel 3-50
defining 1-12, 3-31
definition of 1-7
Definition panel 3-33, A-4
naming conventions 3-41
Processing Sequence panel 3-46
Request panel 3-31
routes 4-4
Sequence Request panel 3-45
updating data set definitions 3-49
Type Processing Sequence
Type sequence 6-44
TYPE=END macro 13-24
TYPE=ENVRNMNT macro 13-18
See also SMF interface
TYPE=MAIN macro 13-5
See also SMF interface
Unloading elements A-3

Update Action
CCIDs 8-8
function 1-19
Updating
Add Action CCIDs 8-6
CCIDs with Update Action 8-8
Delete Action CCIDs 8-11
Generate Action CCIDs 8-8
Move Action CCIDs 8-9
Restore Action CCIDs 8-12
Retrieve Action CCIDs 8-8
Transfer Action CCIDs 8-10
User
exit program C-5
Index X-7
User (continued)
Options Menu 11-2, 11-4
Using
inventory structure 1-7
panels 3-2
panels to define a map 4-3
Point in Time Recovery 15-10
Subsystem Definition panel 3-29
System Definition panel 3-19
Type
Data Set Request panel 3-49
Definition panel 3-33
Request panel 3-32
Sequence Request panel 3-45
Utilities
BC1JRELD A-4
BC1JVALD A-5
BC1PNCPY 15-9
CONWRITE 15-3, 15-14
Reload A-4
Validate A-5
Validate utility A-5

Validating CCIDs 8-14
VSAM
file processing 15-10
LOG attribute 15-12
record level sharing (RLS)
WITH HISTORY A-7

Working with elements
1-18
15-12

Allfusion® Endevor® Change Manager: Administrator Guide R7

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Allfusion® Endevor® Change Manager: Administrator Guide R7

Uploaded by

Copyright:

Available Formats

AllFusion Endevor

First Edition, February 2005

Chapter 2. A Conceptual View of Endevor . . . . . . . . . . .

2.2 Change Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

3.2.2.5 Control Data Set Names Fields . . . . . . . . .

3.8.1 Type Sequence Request Panel . . . . . . . .

Chapter 5. Element Registration

6.6.4 Step 3: Set the AllFusion CA-Panvalet Parameters in the

Chapter 8. Using CCIDs . . . . . . . . . . . . . . . . . . . . . .

8.4.5.1 Specifying a Generate Action without Copyback

viii Administrator Guide

Chapter 9. SMF Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 10. Global Type Sequencing . . . . .

10.2.3 Build Utility for the Type Sequence Member

Chapter 12. The ISPF Dialog Options Configuration Table

Chapter 14. The Alternate Defaults Table

15.3.1 Two Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Appendix C. Interfacing Endevor with CA Common Services

Appendix F. Email Notification .

xii Administrator Guide

Chapter 1. Overview 1-1

1.1 The Defaults Table

1.1 The Defaults Table

1-2 Administrator Guide

1.2 The Software Life Cycle

1.2 The Software Life Cycle

1.2.1 Basic Operations

Chapter 1. Overview 1-3

1.2 The Software Life Cycle

The following diagram shows normal change procedures in a software life

Emergency change procedures include:

1-4 Administrator Guide

1.2 The Software Life Cycle

The following diagram illustrates emergency change procedures in a software

Chapter 1. Overview 1-5

1.3 Endevor Logical Structure

1.3 Endevor Logical Structure

Functional areas within an organization. For example, there

The applications at a site. For example, there might be

A specific application within a system. For example, there

1-6 Administrator Guide

1.3 Endevor Logical Structure

Categories of source code. For example, you might create the

Partitioned data set (PDS) members, AllFusion

1.3.1 Using the Inventory Structure

1.3.2 Setting Up Endevor

Chapter 1. Overview 1-7

1.3 Endevor Logical Structure

1.3.2.1 Step 1: Determine Life Cycle Stages

1.3.2.2 Step 2: Decide Stages for Endevor Control

This means that program development takes place outside of Endevor.

1.3.2.3 Step 3: Define Environments

1-8 Administrator Guide

1.3 Endevor Logical Structure

The Environment Map The Endevor administrator might decide to establish

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

Chapter 1. Overview 1-9

1.3 Endevor Logical Structure

1.3.2.4 Step 4: Define Systems

1-10 Administrator Guide

1.3 Endevor Logical Structure

1.3.2.5 Step 5: Define Subsystems

Chapter 1. Overview 1-11