AllFusion Endevor®

Change Manager
Administration Guide
4.0

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

December 2002

 2002 Computer Associates International, Inc.

All rights reserved.

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

Chapter 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

1.1 Endevor Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
1.2 The Defaults Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
1.3 The Software Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
1.3.1 Basic Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
1.4 Endevor Logical Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
1.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
1.4.2 Using the Inventory Structure . . . . . . . . . . . . . . . . . . . . . . . 1-8
1.4.3 Setting Up Endevor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
1.4.3.1 Step 1: Determine Life Cycle Stages . . . . . . . . . . . . . . . . . 1-9
1.4.3.2 Step 2: Decide Stages for Endevor Control . . . . . . . . . . . . . 1-9
1.4.3.3 Step 3: Define Environments . . . . . . . . . . . . . . . . . . . . . 1-9
1.4.3.4 Step 4: Define Systems . . . . . . . . . . . . . . . . . . . . . . . 1-10
1.4.3.5 Step 5: Define Subsystems . . . . . . . . . . . . . . . . . . . . . 1-11
1.4.3.6 Step 6: Define Types . . . . . . . . . . . . . . . . . . . . . . . . 1-12
1.4.4 Classifying Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
1.4.4.1 Querying the Endevor Structure . . . . . . . . . . . . . . . . . . 1-15
1.5 Endevor Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
1.5.1 Library List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
1.6 Working with Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
1.6.1 Endevor Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
1.6.2 Actions by Job Function . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
1.6.3 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
1.6.4 Source and Output Management . . . . . . . . . . . . . . . . . . . . . 1-21
1.6.5 Creating Executable Forms of Elements . . . . . . . . . . . . . . . . 1-21
1.6.6 Audit Stamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
1.6.7 Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
1.7 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23
1.7.1 Two Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23
1.7.2 Endevor and Data Set Security . . . . . . . . . . . . . . . . . . . . . 1-23
1.8 Other Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
1.9 Documentation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25
1.10 Name Masking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
1.10.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26

Chapter 2. Defining Inventory Structures . . . . . . . . . . . . . . . . . . . . 2-1

2.1 Basic Panel Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
2.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
2.1.2 The Environment Options Menu . . . . . . . . . . . . . . . . . . . . . . 2-3

Contents iii
 2.1.3 Request and Selection Panels . . . . . . . . . . . . . . . . . . . . . . . 2-4
2.2 Displaying Site Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
2.2.1 Site Information Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
2.2.2 Site Information Panel Fields . . . . . . . . . . . . . . . . . . . . . . . 2-7
2.2.2.1 Customer Name Field . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
2.2.2.2 Function Controls Fields . . . . . . . . . . . . . . . . . . . . . . . 2-7
2.2.2.3 Options Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
2.2.2.4 Package Processing Fields . . . . . . . . . . . . . . . . . . . . . 2-12
2.2.2.5 Control Data Set Names Fields . . . . . . . . . . . . . . . . . . . 2-13
2.2.2.6 CA-7 Data Set Name Fields . . . . . . . . . . . . . . . . . . . . 2-13
2.3 Displaying Stage Information . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
2.3.1 Stage Information Panel . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
2.3.2 Stage Information Panel Fields . . . . . . . . . . . . . . . . . . . . . 2-14
2.4 Defining Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
2.4.1 System Request Panel . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
2.4.2 Procedure: New System . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
2.4.3 System Definition Panel . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
2.4.4 Using the System Definition Panel . . . . . . . . . . . . . . . . . . . 2-17
2.4.5 System Definition Panel Fields . . . . . . . . . . . . . . . . . . . . . 2-18
2.4.5.1 Identification Fields . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
2.4.5.2 General Options Fields . . . . . . . . . . . . . . . . . . . . . . . 2-19
2.4.5.3 Element Registration Options: . . . . . . . . . . . . . . . . . . . 2-19
2.4.5.4 Signin/Signout Options Fields . . . . . . . . . . . . . . . . . . . 2-21
2.4.5.5 Last System Backup Fields . . . . . . . . . . . . . . . . . . . . . 2-21
2.4.5.6 Processor Translation Output Libraries Fields . . . . . . . . . . . 2-22
2.5 Cloning System, Subsystem, and Type Definitions . . . . . . . . . . . . . 2-23
2.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
2.5.2 Procedure: Cloning a New System . . . . . . . . . . . . . . . . . . . 2-23
2.5.3 System Definition Panel for Cloning . . . . . . . . . . . . . . . . . . 2-24
2.5.4 System Definition Panel Fields . . . . . . . . . . . . . . . . . . . . . 2-24
2.5.4.1 To Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24
2.5.4.2 From Information . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25
2.5.4.3 General Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25
2.6 Defining Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26
2.6.1 Subsystem Request Panel . . . . . . . . . . . . . . . . . . . . . . . . . 2-26
2.6.2 Procedure: Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26
2.6.3 Subsystem Definition Panel . . . . . . . . . . . . . . . . . . . . . . . 2-26
2.6.4 Using the Subsystem Definition Panel . . . . . . . . . . . . . . . . . 2-27
2.6.5 Subsystem Definition Panel Fields . . . . . . . . . . . . . . . . . . . . 2-27
2.7 Defining Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
2.7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
2.7.2 Type Request Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
2.7.3 Procedure: Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
2.7.4 Type Definition Panel . . . . . . . . . . . . . . . . . . . . . . . . . . 2-31
2.7.5 Using the Type Definition Panel . . . . . . . . . . . . . . . . . . . . . 2-31
2.7.6 Type Definition Panel Fields . . . . . . . . . . . . . . . . . . . . . . . 2-32
2.7.6.1 Identification Fields . . . . . . . . . . . . . . . . . . . . . . . . . 2-32
2.7.6.2 Element Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-33
2.7.6.3 Component List Options . . . . . . . . . . . . . . . . . . . . . . 2-37
2.7.6.4 Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37
2.7.7 Type Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . 2-38

iv Administration Guide
 2.7.8 Suggested Naming Standards . . . . . . . . . . . . . . . . . . . . . . 2-38
2.7.9 Element Storage Formats . . . . . . . . . . . . . . . . . . . . . . . . . 2-39
2.7.9.1 Reverse Delta Considerations . . . . . . . . . . . . . . . . . . . . 2-39
2.7.9.2 Forward Delta Considerations . . . . . . . . . . . . . . . . . . . 2-39
2.7.9.3 Full-Image Delta Considerations . . . . . . . . . . . . . . . . . . 2-40
2.7.10 Using Symbolics to Define Base and Delta Libraries . . . . . . . . . 2-40
2.8 Defining the Type Processing Sequence . . . . . . . . . . . . . . . . . . . 2-42
2.8.1 Type Sequence Request Panel . . . . . . . . . . . . . . . . . . . . . . 2-42
2.8.2 Procedure: Type Processing Sequence . . . . . . . . . . . . . . . . . . 2-42
2.8.3 Type Processing Sequence Panel . . . . . . . . . . . . . . . . . . . . 2-43
2.8.3.1 Type Processing Sequence Panel Fields . . . . . . . . . . . . . . 2-44
2.9 Updating Type Data Set Definitions . . . . . . . . . . . . . . . . . . . . . 2-46
2.9.1 Type Data Set Request Panel . . . . . . . . . . . . . . . . . . . . . . 2-46
2.9.2 Procedure: Type Data Set Definitions . . . . . . . . . . . . . . . . . . 2-46
2.9.3 Type Data Set Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-47
2.9.3.1 Type Data Set Panel Fields . . . . . . . . . . . . . . . . . . . . . 2-47
2.10 Displaying Environment Information . . . . . . . . . . . . . . . . . . . . 2-49
2.10.1 Environment Information Panel . . . . . . . . . . . . . . . . . . . . . 2-49
2.10.1.1 Environment Information Panel Fields . . . . . . . . . . . . . . 2-49

Chapter 3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

3.1 What Is a Map? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
3.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
3.1.2 Defining a Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
3.1.3 Establishing Routes in the Defaults Table . . . . . . . . . . . . . . . . . 3-3
3.1.4 Mapping Inventory Classifications . . . . . . . . . . . . . . . . . . . . . 3-4
3.2 Design Strategies and Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 3-5
3.2.1 Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
3.2.2 Stand-alone Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
3.2.3 Converging Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
3.2.4 Converging Systems within a Route . . . . . . . . . . . . . . . . . . . . 3-7
3.2.5 Implementation Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8

Chapter 4. Site Symbolics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

4.1 Site-Defined Symbolics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
4.2 Site Symbolics Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
4.2.1 Defining Site Symbolics . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
4.2.2 Updating C1DEFLTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4

Chapter 5. Element Registration . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
5.2 Controlling Duplicate Element Names at the System and Subsystem Level . 5-3
5.3 Controlling Duplicate Element Names at the Processor Group Level . . . . 5-4
5.3.1 Defining the Output Type . . . . . . . . . . . . . . . . . . . . . . . . . 5-5

Chapter 6. Using CCIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
6.2 What CCIDs and/or Comments Indicate . . . . . . . . . . . . . . . . . . . . 6-3
6.2.1 Six Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
6.3 Requiring CCIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4

Contents v
 6.3.1 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
6.3.2 Action Prompt Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
6.4 When Endevor Updates CCID Fields . . . . . . . . . . . . . . . . . . . . . . 6-6
6.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
6.4.2 Add Action CCID Updates . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
6.4.2.1 Specifying an Add Action for a New Element . . . . . . . . . . . 6-7
6.4.2.2 Specifying an Add Action for an Existing Element . . . . . . . . . 6-7
6.4.3 Update Action CCID Updates . . . . . . . . . . . . . . . . . . . . . . . 6-7
6.4.4 Retrieve Action CCID Updates . . . . . . . . . . . . . . . . . . . . . . 6-8
6.4.5 Generate Action CCID Updates . . . . . . . . . . . . . . . . . . . . . . 6-8
6.4.5.1 Specifying a Generate Action without Copyback . . . . . . . . . . 6-8
6.4.5.2 Specifying a Generate Action with Copyback . . . . . . . . . . . . 6-8
6.4.6 Move Action CCID Updates . . . . . . . . . . . . . . . . . . . . . . . . 6-9
6.4.6.1 Specifying a Move Action without History . . . . . . . . . . . . . 6-9
6.4.6.2 Specifying a Move Action with History . . . . . . . . . . . . . . . 6-9
6.4.7 Transfer Action CCID Updates . . . . . . . . . . . . . . . . . . . . . . 6-9
6.4.7.1 Specifying a Transfer Action without History . . . . . . . . . . . . 6-9
6.4.7.2 Specifying a Transfer Action with History . . . . . . . . . . . . 6-10
6.4.8 Delete Action CCID Updates . . . . . . . . . . . . . . . . . . . . . . 6-10
6.4.9 Restore Action CCID Updates . . . . . . . . . . . . . . . . . . . . . . 6-11
6.4.10 Summary CCID Impact Chart . . . . . . . . . . . . . . . . . . . . . 6-11
6.5 Predefining CCIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13
6.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13
6.5.2 CCID Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13
6.5.3 Endevor CCID Definition Data Set . . . . . . . . . . . . . . . . . . . 6-14
6.5.3.1 Creating a CCID Definition Data Set . . . . . . . . . . . . . . . 6-14
6.5.3.2 The Purpose of a Sequential Data Set . . . . . . . . . . . . . . . 6-14
6.5.3.3 Editing the File Using the ISPF Text Editor . . . . . . . . . . . . 6-15
6.5.4 Using the CCID Definition Data Set . . . . . . . . . . . . . . . . . . 6-15
6.5.4.1 Sample CCID Definition Data Set . . . . . . . . . . . . . . . . . 6-16

Chapter 7. SMF Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
7.1.1 SMF Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
7.2 Record Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
7.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
7.2.2 SMF Security Records . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
7.2.3 SMF Action Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
7.3 DSECT Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
7.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
7.3.2 $SMFHDDS DSECT: SMF Header Block . . . . . . . . . . . . . . . . 7-6
7.3.2.1 SMF Header Block Field Descriptions . . . . . . . . . . . . . . . . 7-7
7.3.3 $SMFREC1 DSECT: Security Record Data Block . . . . . . . . . . . . 7-8
7.3.3.1 Security Record Data Block Field Descriptions . . . . . . . . . . 7-10
7.3.4 $SMFREC2 DSECT: Action Record Data Block . . . . . . . . . . . . 7-12
7.3.4.1 Action Record Data Block Field Descriptions . . . . . . . . . . . 7-13
7.3.5 $SMFBKDS DSECT: Action-Specific Blocks . . . . . . . . . . . . . 7-13
7.3.5.1 Action-Block Header Field Descriptions (SM2BHDDS) . . . . . 7-17
7.3.5.2 Environment Action-Block Detail Field Descriptions
(SM2ENVDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17
7.3.5.3 Last Change Action-Block Detail Field Descriptions (SM2LCGDS) 7-19

vi Administration Guide
 7.3.5.4 Processor Information Action-Block Detail Field Descriptions
(SM2LPRDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20
7.3.5.5 Request Parameter Info Action-Block Detail Field Descriptions
(SM2REQDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20

Chapter 8. The User Options Menu Facility . . . . . . . . . . . . . . . . . . . 8-1

8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
8.1.1 Menu Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
8.2 User Option Menu Panel Overview . . . . . . . . . . . . . . . . . . . . . . . 8-3
8.2.1 Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
8.2.2 Modifying the User Options Menu . . . . . . . . . . . . . . . . . . . . 8-4

Chapter 9. Performance and Tuning . . . . . . . . . . . . . . . . . . . . . . . 9-1

9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
9.2 Choosing Between Delta Formats . . . . . . . . . . . . . . . . . . . . . . . . 9-3
9.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
9.2.2 Converting from Forward to Reverse Deltas . . . . . . . . . . . . . . . 9-4
9.2.3 Full-Image Deltas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4
9.3 Setting the Element Delta Consolidation Level . . . . . . . . . . . . . . . . 9-5
9.3.1 Two Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5
9.4 Mapping Multiple Environments . . . . . . . . . . . . . . . . . . . . . . . . 9-6
9.4.1 Before Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6
9.5 Selecting a Library Type for Base and Delta Members . . . . . . . . . . . . 9-7
9.5.1 Benefits of Library Types . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
9.5.2 Converting from One Library Type to Another . . . . . . . . . . . . . . 9-8
9.6 Using L-Serv for Endevor's VSAM File Processing . . . . . . . . . . . . . . 9-9
9.6.1 Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9
9.6.2 Setting the RECBUFFSIZE Parameter . . . . . . . . . . . . . . . . . . 9-9
9.6.3 Monitoring L-Serv's Performance . . . . . . . . . . . . . . . . . . . . . 9-9
9.6.3.1 Evaluating Buffer Pool Usage . . . . . . . . . . . . . . . . . . . 9-10
9.6.3.2 Displaying Information about the Communications Server . . . . 9-10
9.7 Using OS/390 SYSPLEX VSAM Record Level Sharing (RLS) Support for
MCFs and Package Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
9.7.1 Implementing RLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
9.8 Tuning Your Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
9.8.1 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
9.9 Tuning Your System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
9.9.1 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14

Appendix A. Converting Delta Formats . . . . . . . . . . . . . . . . . . . . . A-1

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

Contents vii
 A.2 Additional Conversion Notes . . . . . . . . . . . . . . . . . . . . . . . . . . A-6
A.2.1 Reverse Delta Format . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6
A.3 Procedure for Converting Forward/Reverse Delta to Full-Image Delta . . . A-7

Appendix B. Interfacing Endevor with CA Common Services . . . . . . . . B-1

B.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2
B.2 Formatting Endevor Messages . . . . . . . . . . . . . . . . . . . . . . . . . B-3
B.3 How the Interface Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-4
B.4 Calling the Interface From a User Exit . . . . . . . . . . . . . . . . . . . . . B-5
B.5 Calling the Interface From a Processor . . . . . . . . . . . . . . . . . . . . . B-6
B.5.1 Sample Endevor Processor Fragment . . . . . . . . . . . . . . . . . . . B-6
B.5.2 REXX Procedure Sample . . . . . . . . . . . . . . . . . . . . . . . . . B-7
B.6 Setting Up the IP Addresses of Event Consoles . . . . . . . . . . . . . . . . B-9

Appendix C. Long Name and HFS File Support . . . . . . . . . . . . . . . . C-1

C.1 Long Name and HFS Support Overview . . . . . . . . . . . . . . . . . . . . C-2
C.1.1 HFS Path Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2
C.1.2 HFS Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2
C.1.3 Element Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-3
C.1.4 Long Name Support and Endevor Interfaces . . . . . . . . . . . . . . . C-4
C.2 Long Name Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-6
C.2.1 Adding and Retrieving Long Name Elements . . . . . . . . . . . . . . C-6
C.2.2 Storing Long Name Elements . . . . . . . . . . . . . . . . . . . . . . . C-7
C.2.3 Displaying Element Information . . . . . . . . . . . . . . . . . . . . . . C-7
C.3 HFS Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-8
C.3.1 HFS Directories and Endevor Libraries . . . . . . . . . . . . . . . . . . C-8
C.3.2 Using Site Symbolics for Type Definitions . . . . . . . . . . . . . . . . C-8
C.3.3 HFS Directories and Endevor Actions . . . . . . . . . . . . . . . . . . C-9
C.3.4 HFS Files and Endevor Actions . . . . . . . . . . . . . . . . . . . . . . C-9
C.4 HFS RECFM Field in Type Definition Panel . . . . . . . . . . . . . . . . C-10
C.4.1 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-10

Appendix D. Catalog Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . D-1

D.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-2
D.2 Building the Element Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . D-3
D.2.1 Step 1: Converting Your Existing MCF VSAM Data Sets . . . . . . . D-3
D.2.1.1 BC1JXMCF JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . D-3
D.2.2 Step 2: Converting Your Existing Package VSAM Data Sets . . . . . . D-5
D.2.2.1 BC1JXPCF JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-5
D.2.3 Step 3: Defining the MCF Catalog Data Set . . . . . . . . . . . . . . . D-8
D.2.3.1 BC1JJB07 JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-8
D.2.4 Step 4: Updating the C1DEFLTS Table . . . . . . . . . . . . . . . . . D-9
D.2.5 Step 5: Running the Catalog Build Utility . . . . . . . . . . . . . . . . D-9
D.2.5.1 BC1JXCAT JCL . . . . . . . . . . . . . . . . . . . . . . . . . . D-10
D.3 Endevor Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-11
D.4 Catalog Rename Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-12
D.4.1 BC1JXCNM JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-12
D.4.2 Sample Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-14

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

viii Administration Guide

Chapter 1. Overview

Chapter 1. Overview 1-1

1.1 Endevor Overview

1.1 Endevor Overview

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 OS/390, 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.

1-2 Administration Guide

 1.2 The Defaults Table

1.2 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 Installation Guide for a sample of the C1DEFLTS table and a detailed
description of the parameters available within the table.

Chapter 1. Overview 1-3

1.3 The Software Life Cycle

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

1-4 Administration Guide

 1.3 The Software Life Cycle

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.

Chapter 1. Overview 1-5

1.3 The Software Life Cycle

The following diagram illustrates emergency change procedures in a software life

cycle.

1-6 Administration Guide

 1.4 Endevor Logical Structure

1.4 Endevor Logical Structure

1.4.1 Overview
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.3, “The Software Life
Cycle” on page 1-4 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.

Chapter 1. Overview 1-7

1.4 Endevor Logical Structure

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,
AllFusion CA-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.4.2 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.4.3 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-8 Administration Guide

 1.4 Endevor Logical Structure

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

Chapter 1. Overview 1-9

1.4 Endevor Logical Structure

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

1.4.3.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-10 Administration Guide

 1.4 Endevor Logical Structure

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

Chapter 1. Overview 1-11

1.4 Endevor Logical Structure

1.4.3.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-12 Administration Guide

 1.4 Endevor Logical Structure

1.4.4 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:

Chapter 1. Overview 1-13

1.4 Endevor Logical Structure

1-14 Administration Guide

 1.4 Endevor Logical Structure

For example, in this diagram:

This module Is located in Is classified as

PROG01 Environment TEST Type COBOL
Stage UNITTEST Subsystem PO
System FINANCE
JCL22Q Environment TEST Type JCL
Stage QA Subsystem MFG
System MFG
COPY33 Environment TEST Type COPYBOOK
Stage QA Subsystem AP
System FINANCE

1.4.4.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 PGMA1
tested PGMA2
MAC02

Chapter 1. Overview 1-15

1.5 Endevor Libraries

1.5 Endevor Libraries

1.5.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 There is one Master Control File (MCF) for every stage. A Master Control File
libraries 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. The element
catalog contains an alternate index so an element catalog record can be located via
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 246 characters of the element name
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.)
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.

1-16 Administration Guide

 1.5 Endevor Libraries

Library Description
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 Endevor uses these libraries to store the name of each element and its related
Libraries 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 Endevor uses processor load libraries to store the executable form of Endevor
listing libraries
1 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 Used to store compiler listings produced by the CONLIST utility. A single library

1 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.
Processor output These are libraries that you refer to in processors, to which processors write their
libraries
1 output. Processor output libraries can be source libraries, executable libraries, or
listing libraries.
Note:
1 — Processors only

Chapter 1. Overview 1-17

1.5 Endevor Libraries

The table below summarizes where each of these libraries should be allocated in a
sample software life cycle.

Library Name C1DEFLTS DEV DEV QA PROD PROD

TEST EMERG PROD
Master control files x
Element Catalog x
ACM Root library x
ACM XREF library x
Package data set x
Base and delta libraries, by type x x x x
Output libraries, by type x x x x
Source output libraries, by type x x x x
Processor load libraries x
Processor output libraries x x x x
(source, executable, list)
Include libraries, by type x x x x

1-18 Administration Guide

 1.6 Working with Elements

1.6 Working with Elements

1.6.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 Available in Function

Foreground Batch
Add x x Puts a member under Endevor
control from an external data
set.
Archive x Writes the current version of an
element to a sequential data set.
Copy x Copies an element from an
archive data set to a data set
external to Endevor.
Delete x x Erases base and delta forms of
an element and removes related
information from a Master
Control File.
Display x Displays information about an
element.
Generate x x Creates an executable form of
an element.
List x Creates a list of elements that
meet specific selection criteria.
One effective use of this
function is to perform impact
analysis.
Move x x Moves elements between stages,
within or across environments.

Chapter 1. Overview 1-19

1.6 Working with Elements

Action Available in Available in Function

Foreground Batch
Print x x Prints element or member
information.
Restore x Restores elements to Endevor
from an archive data set.
Retrieve x x Copies elements from Endevor
to an external data set.
Signin x x Removes the user signout
associated with an element.
Transfer x Moves elements between
locations that are not on the
same map route.
Update x x Updates an element from an
external data set.

1.6.2 Actions by Job Function

A typical site might include the following job functions:
■ Development
■ QA/Test
■ Turnover
■ Audit
■ Management
■ Endevor administration

The table below summarizes, for each job function, the actions that someone might
perform:

Action Dev QA/Test Turnover Audit Mgmnt Admin

Add/Update x x x
Archive x
Copy x
Delete x x
Display x x x x x x
Generate x
List x x

1-20 Administration Guide

 1.6 Working with Elements

Action Dev QA/Test Turnover Audit Mgmnt Admin

Move x x x x
Print x x x x x x
Restore x
Retrieve x x x
Signin x x x
Transfer x x

1.6.3 Reporting
Endevor provides a full set of standard reports, see the Reports Guide for more
information.

1.6.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.6.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
Stage 1, 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 re-create those outputs in the target stage.

Chapter 1. Overview 1-21

1.6 Working with Elements

■ 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.6.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.6.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-22 Administration Guide

 1.7 Security

1.7 Security

1.7.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 OS/390 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, eTrust CA-Top Secret) rather than in the
native tables supplied with Endevor. For more information on enabling and using
Endevor ESI, see the Security Guide.

1.7.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
■ eTrust CA-Top Secret

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.

Chapter 1. Overview 1-23

1.8 Other Capabilities

1.8 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's Information/Management System
– Advantage CA-Roscoe
– AllFusion CA-Panvalet and AllFusion CA-Librarian
– Unicenter CA-7
– Unicenter CA-Netman

1-24 Administration Guide

 1.9 Documentation Overview

1.9 Documentation Overview

This manual is part of a comprehensive documentation set that fully describes the
features and functions of Endevor and explains how to perform everyday tasks. For a
complete list of Endevor manuals, see the PDF Table of Contents file in the PDF
directory, or the Bookmanager Bookshelf file in the Books directory.

The following section describes product conventions.

Chapter 1. Overview 1-25

1.10 Name Masking

1.10 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

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.10.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.
Note: You cannot use more than one wildcard in a string. The statement ADD
ELEMENT U*PD* would result in an error.

The placeholder (%) 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

1-26 Administration Guide

 1.10 Name Masking

with four-character-long names beginning with "UPD" (UPD1 or UPDA, for

example) would be added.
■ 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. An example of a
statement using both the wildcard and the placeholder is ADD ELEMENT U%D*.
This statement would add elements with names of any length that have U as the first
character and D as the third.

Chapter 1. Overview 1-27

1-28 Administration Guide
Chapter 2. Defining Inventory Structures

Chapter 2. Defining Inventory Structures 2-1

2.1 Basic Panel Flow

2.1 Basic Panel Flow

2.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 Primary Options Menu.

 ---------------- AllFusion Endevor Primary Options Panel ----------------------


Option ===> 4

 DEFAULTS - Specify Endevor ISPF default parameters

1 DISPLAY - Perform Display functions
2 FOREGROUND - Execute Foreground Actions
3 BATCH - Perform Batch Action processing
4 ENVIRONMENT - Define or Modify Environment information
5 PACKAGE - Perform Foreground Package processing
6 BATCH PACKAGE - Perform Batch Package SCL Generation
U USER MENU - Display user option menu
T TUTORIAL - Display information about Endevor
C CHANGES - Display summary of changes for this release of Endevor
X EXIT - Exit the Endevor dialog

Current environment: SMPLTEST

(C) 22 Computer Associates International, Inc.

Use the EXIT option to terminate Endevor

 
3. Select option 4 (ENVIRONMENT) on the Primary Options Panel and press
ENTER. Endevor displays the Environment Options Menu.

2-2 Administration Guide

 2.1 Basic Panel Flow

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


OPTION ===>

1 SITE - Display site information

2 STAGE - Display stage information
3 SYSTEM - Display, delete, create, update or clone system
4 SUBSYSTEM - Display, delete, create or update subsystem
5 TYPE - Display, delete, create or update type definitions
6 PROCESSOR GROUP - Display, delete, create or update processor groups
7 TYPE SEQUENCE - Display or update type processing sequence
8 DATA SET - Display or update type data sets
9 APPROVER GROUP - Display, delete, create or update approver groups
A RELATE GROUP - Relate approver groups to systems, subsystems, etc.
D DESTINATION - Display, delete, create or update shipment destinations
E ENVIRONMENT - Display information about the current environment
S SITE SYMBOLS - Display site symbol definitions

 
4. To select an option, type the appropriate number or letter (1-9, A, D, E, 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 Primary Options Panel by pressing END
repeatedly. To return to the invoking facility (ISPF or TSO) from the Primary
Options Panel, press END, or type END in the OPTION field and press ENTER.

2.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 4, “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

1 Display site definitions, as specified to the Endevor
Defaults Table.
2 Display the two stage definitions for an environment.
3 Display, delete, create, update, or clone (copy) the
definition and/or mapping of a system.
4 Display, delete, create, or update the definition and/or
mapping of a subsystem.
5 Display, delete, create, or update the definition and/or
mapping of a type.
6 Display, delete, create, or update the definition and/or
mapping of a processor group.
7 Display or update the relative sequence of execution for
Endevor actions, for all element types defined to a
particular system.

Chapter 2. Defining Inventory Structures 2-3

2.1 Basic Panel Flow

Use this option To

8 Change the data sets defined for use with a specific
system.
9 Display, delete, create, or update approver groups.
A Establish relationships between approver groups and
inventory areas within an environment.
D Display, delete, create, or update destinations for package
shipments.
E Display environment definitions, as specified in the
Endevor Defaults Table.
S Display the site symbolics table. The table is specified in
the C1DEFLTS table.

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

 ----------------------------- TYPE REQUEST ----------------------------------


OPTION ===>

blank - Display type definition

# - Delete type definition
C - Create type definition
U - Update type definition

ENVIRONMENT ===> SMPLTEST

SYSTEM ===>

TYPE ===>

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

 
You use these panels to request a particular function (display, delete, create, 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:

2-4 Administration Guide

 2.1 Basic Panel Flow

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


COMMAND ===> SCROLL ===> CSR

CURRENT ENV: SMPLTEST

NEXT ENV: SMPLPROD

SYSTEM SYSTEM TITLE

ADMIN ENDEVOR ADMINISTRATION SYSTEM
FINANCE FINANCIAL SYSTEM
 BOTTOM OF DATA
 
Selection List panels allow you to select a system, subsystem, or type 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.

Chapter 2. Defining Inventory Structures 2-5

2.2 Displaying Site Information

2.2 Displaying Site Information

2.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-LSERV 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 Security..ESI
Foreground Exec..Y Comp Validation...O
Generated High-lvl Index for Remote PKG JCL........ ENDEVOR

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

Element Catalog...................CA.ENDEVOR.ELMCATL
Package Control File..............CA.ENDEVOR.VSAMRLS.PACKAGE
Endevor Macro Library.............CA.ENDEVOR.MACLIB
CCID Validation Data Set..........
ACM Query Root Data Set...........CA.ENDEVOR.ACMROOT
ACM Query Xref Data Set...........CA.ENDEVOR.ACMXREF

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

2-6 Administration Guide

 2.2 Displaying Site Information

2.2.2 Site Information Panel Fields

This section describes the panel fields. For more information about these fields, see the
Installation Guide.

2.2.2.1 Customer Name Field

Your company name appears at the top of this screen.

2.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).
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 above.
■ 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.

Chapter 2. Defining Inventory Structures 2-7

2.2 Displaying Site Information

Field Description
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 signout an element to a user who performs a
Generate in-place action.
CA-LServ SUBSYS 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. of this parameter enables journaling of changes to
Master Control Files and the 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. For more information,
see the Installation Guide.
Access Tbl Name of the Access Security Table currently in use
(applicable for native security).

2-8 Administration Guide

 2.2 Displaying Site Information

Field Description
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
Librarian 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/page Number of lines printed per page, for reports generated by
Endevor.

Chapter 2. Defining Inventory Structures 2-9

2.2 Displaying Site Information

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 OS/390 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.

2-10 Administration Guide

 2.2 Displaying Site Information

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.

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

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

Chapter 2. Defining Inventory Structures 2-11

2.2 Displaying Site Information

2.2.2.4 Package Processing Fields

These fields are display-only.

Field Description
Approval Indicates whether packages must be approved: Y or N
Foreground Execution Indicates whether packages may be executed in
foreground.
Generated High-lvl The data set name used for remote package shipments.
Index for Remote PKG
JCL
Cast Security Indicates whether to check security authorizations for every
action in a package for the user ID requesting package
cast: Y or N
Component 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.
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 CA-ACF2,
CA-Top Secret, or IBM RACF via 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

2-12 Administration Guide

 2.2 Displaying Site Information

2.2.2.5 Control Data Set Names Fields

The following fields are display-only.

Field Description
Element Catalog Name of the file containing the element catalog. For more
information, see 1.5, “Endevor Libraries” on page 1-16.
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 Data set name of the sequential file containing the
Set definitions of the valid CCIDs established for this site.
This field is blank if CCID validation is not in use.
ACM Query Root Data The name of the VSAM file your site uses to store the
Set name of each Endevor element and all its related
components. The recommended name is
uprfx.uqual.ACMROOT.
ACM Query Xref Data The name of the VSAM file your site uses to store the
Set name of each Endevor component relationship. The
recommended name is uprfx.uqual.ACMROOT.

2.2.2.6 CA-7 Data Set Name Fields

The following fields are display-only.

Field Description
CA-7 Region CCI CCI Nodename assigned to the CA-7 address space.
Nodename
JCL Data Set Index Sequence number associated with the CA-7 DEMAND
Number JCL library.
JCL Data Set Index Symbol associated with the CA-7 DEMAND JCL library.
Symbol
JCL Data Set Name Data Set name of the CA-7 JCL DEMAND library.

Chapter 2. Defining Inventory Structures 2-13

2.3 Displaying Stage Information

2.3 Displaying Stage Information

2.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: T
Name: TEST
Title: UNIT TEST
MCF data set name: CA.ENDEVOR.SMPLTEST.MCF

STAGE 2 INFORMATION:
ID: Q
Name: QA
Title: QUALITY ASSURANCE
MCF data set name: CA.ENDEVOR.SMPLQA.MCF

 
When you finish viewing the Stage Information display, either fill in the 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.

2.3.2 Stage Information Panel Fields

This section describes the panel fields. For more information about the displayed
fields, see the Installation Guide.

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.
Stage 1 Information Stage 1 definition information includes:

1
■ ID — Stage 1 ID
■ Name — Stage 1 name
■ Title — Stage 1 title

2-14 Administration Guide

 2.3 Displaying Stage Information

Field Description
MCF data set name Data set name of the Stage 1 Master Control File (MCF).
Stage 2 Information Stage 2 definition information includes:

1
■ 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).
Note:

1: These fields are display only.

Chapter 2. Defining Inventory Structures 2-15

2.4 Defining Systems

2.4 Defining Systems

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

 ---------------------------- SYSTEM REQUEST ---------------------------------


OPTION ===> k

blank - Display system definition

# - Delete system definition
C - Create system definition
K - Clone system structure
U - Update system definition

ENVIRONMENT ===> SMPLtest

SYSTEM ===> admin

 

2.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
2.5, “Cloning System, Subsystem, and Type Definitions” on page 2-23.
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.

2-16 Administration Guide

 2.4 Defining Systems

2.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 LIBRARIES:

STAGE 1 LOAD LIBRARY ===> CA.ENDEVOR.SMPLEMER.PRCSLOAD
STAGE 1 LIST LIBRARY ===> CA.ENDEVOR.SMPLEMER.PRCSLIST
STAGE 2 LOAD LIBRARY ===> CA.ENDEVOR.SMPLPROD.PRCSLOAD
STAGE 2 LIST LIBRARY ===> CA.ENDEVOR.SMPLPROD.PRCSLIST
 
Note: A different panel, specific to clone processing, is returned if you request clone
processing. For more information on this panel, see 2.5, “Cloning System, Subsystem,
and Type Definitions” on page 2-23.

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

Chapter 2. Defining Inventory Structures 2-17

2.4 Defining Systems

2.4.5 System Definition Panel Fields

This section describes the panel fields.

2.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 Name of the next environment on the map.
System
1 Name of the current system.
Next System Name of this system in the next environment. 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:

1: These fields are display only.

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.

2-18 Administration Guide

 2.4 Defining Systems

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

2.4.5.3 Element Registration Options:

These fields contain definitions of the element registration features in effect for this
system.

Field Description
Duplicate Element Specifies if Endevor checks to see if the element name is
Name Check used in any other subsystems within in 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.

Chapter 2. Defining Inventory Structures 2-19

2.4 Defining Systems

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 another
subsystem under the same system; the action is
performed and a warning message is issued.
■ E — The same element name exists within another
subsystem under the same system; the 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 Specifies if Endevor should check for duplicate element
Type Check 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.

2-20 Administration Guide

 2.4 Defining Systems

2.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.
For a description of this facility, see the User Guide.
Validate Data Set Acceptable values are:
■ 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.

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

Field Description
Date Date of most recent system backup.
Time Time of most recent system backup.

Chapter 2. Defining Inventory Structures 2-21

2.4 Defining Systems

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

2-22 Administration Guide

 2.5 Cloning System, Subsystem, and Type Definitions

2.5 Cloning System, Subsystem, and Type Definitions

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

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

Chapter 2. Defining Inventory Structures 2-23

2.5 Cloning System, Subsystem, and Type Definitions

2.5.3 System Definition Panel for Cloning

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


COMMAND ===>

TO INFORMATION:
ENVIRONMENT: SMPLTEST
SYSTEM: ADMIN
TITLE ===> Endevor Administrative Applications

FROM INFORMATION:
ENVIRONMENT ===> SMPLprod
SYSTEM ===> admin

GENERAL OPTIONS:
COPY SUBSYSTEMS ===> Y (Y/N)
COPY TYPES ===> Y (Y/N) (TYPES AND PROCESSOR GROUPS)

 

2.5.4 System Definition Panel Fields

This section describes the panel fields.

2.5.4.1 To Information

These fields identify the environment and system for which inventory definitions are
cloned.

Field Description
Environment
1 Name of the current environment.
System
1 Name of the new system.
Title Description of the new system.
Note:

1: These fields are display only.

2-24 Administration Guide

 2.5 Cloning System, Subsystem, and Type Definitions

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

2.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 Acceptable values are:
■ Y — Default. Clone subsystem definitions.
■ N — Do not clone subsystem definitions.
Copy Types Acceptable values are:
■ Y — Default. Clone type and processor group
definitions.
■ N — Do not clone type and processor group
definitions.

Chapter 2. Defining Inventory Structures 2-25

2.6 Defining Subsystems

2.6 Defining Subsystems

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

 --------------------------- SUBSYSTEM REQUEST -------------------------------


OPTION ===> c

blank - Display subsystem definition

# - Delete subsystem definition
C - Create subsystem definition
U - Update subsystem definition

ENVIRONMENT ===> SMPLTEST

SYSTEM ===> ADMIN

SUBSYSTEM ===> Process

 

2.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 2.5,
“Cloning System, Subsystem, and Type Definitions” on page 2-23.
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 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.

2.6.3 Subsystem Definition Panel

Once you have entered the necessary information on the Subsystem Definition panel,
press ENTER to perform the requested processing.

2-26 Administration Guide

 2.6 Defining Subsystems

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


COMMAND ===>

CURRENT ENV: SMPLTEST SYSTEM: ADMIN

NEXT ENV: SMPLTEST SYSTEM: ADMIN

SYSTEM TITLE: Endevor Administration Systems

SUBSYSTEM: PROCESS
TITLE ===> Administration of Endevor - Processors, Tools, etc
NEXT SUBSYSTEM ===> PROCESS

UPDATED: BY

 

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

2.6.5 Subsystem Definition Panel Fields

This section describes the panel fields.

Field Description
Current Env Name of the current environment.
System Name of the current system.
Next Env Name of the next environment on the map.
System Name of the next system on the map.
System Title Descriptive title for the system.
Subsystem Name of the subsystem being processed.
Title Descriptive title for the subsystem (1-50 characters).
Next subsystem Name of this subsystem in the next environment.

Chapter 2. Defining Inventory Structures 2-27

2.6 Defining Subsystems

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

2-28 Administration Guide

 2.7 Defining Types

2.7 Defining Types

2.7.1 Overview
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 100 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.

2.7.2 Type Request Panel

To define a type, select option 5 on the Environment Options panel and press ENTER.
Endevor displays the Type Request panel.

 ----------------------------- TYPE REQUEST ----------------------------------


OPTION ===>

blank - Display type definition

# - Delete type definition
C - Create type definition
U - Update type definition

ENVIRONMENT ===> SMPLTEST

SYSTEM ===> ADMIN

TYPE ===> PROCESS

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

 

Chapter 2. Defining Inventory Structures 2-29

2.7 Defining Types

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

2-30 Administration Guide

 2.7 Defining Types

2.7.4 Type Definition Panel

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


COMMAND ===>

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

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

DESCRIPTION ===> Cobol Source Code

UPDATED: BY
----------------- ELEMENT OPTIONS -------------------
FWD/REV/IMG DELTA ===> R (F/R/I) COMPRESS BASE/ENCRYPT NAME ===> Y (Y/N)
DFLT PROC GRP ===> CLENBL REGRESSION PCT ===> 75 REGR SEV ===> W (I/W/C/E)
SOURCE LENGTH ===> 8 COMPARE FROM ===> 7 COMPARE TO ===> 72
AUTO CONSOL ===> Y (Y/N) LANGUAGE ===> cobol PV/LB LANG ===> DATA
CONSOL AT LVL ===> 96 HFS RECFM ===> NL (COMP/CR/CRLF/F/LF/NL/V)
LVLS TO CONSOL ===> 49 WS HOME OPSYS ===> WS EXT FILE ===>
------------- COMPONENT LIST OPTIONS ----------------
FWD/REV DELTA ===> R (F/R) AUTO CONSOL ===> Y (Y/N) CONSOL AT LVL ===> 96
LVLS TO CONSOL ===> 25
--------------------- LIBRARIES ---------------------
BASE/IMAGE LIBRARY ===> CA.ENDEVOR.SMPL&C1ST..BASE
DELTA LIBRARY ===> CA.ENDEVOR.SMPL&C1ST..DELTA
INCLUDE LIBRARY ===>
SOURCE O/P LIBRARY ===>
EXPAND INCLUDES ===> N (Y/N)
 

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

Chapter 2. Defining Inventory Structures 2-31

2.7 Defining Types

2.7.6 Type Definition Panel Fields

This section describes the panel fields.

2.7.6.1 Identification Fields

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

Field Description
Current Env Name of the current environment.
Stage ID Name of the current stage.
System Name of the current 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 Identifies the date, time, and user ID of the last user to
update the type definition. When creating a new type
definition this field is blank.

CAUTION:
Type names cannot be changed across the map.

2-32 Administration Guide

 2.7 Defining Types

2.7.6.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/ Indicates whether to encrypt and compress the base form
Encrypt Name of elements stored in reverse delta format. Acceptable
values are:
■ N — Do not compress base and encrypt name.
■ Y — Default. Compress base and encrypt name.
Dflt Proc Grp Identifies the processor group for this type. 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.
Regr Sev Determines severity of the error message issued when
Endevor detects regression. Acceptable values are:
■ I — Informational message.
■ W — Warning message.
■ C — Default. Critical message.
■ E — Fatal message.
Source Length 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.
Computer Associates recommends a record length of 4000
for PC binary. element types.
Note: If the source is located in an HFS file, the
maximum record length is 4000 bytes.

Chapter 2. Defining Inventory Structures 2-33

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

2-34 Administration Guide

 2.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 FORTRAN
ALC JCL
AUTOCODE PL/1
BAL RPG
COBOL USER18
COBOL-72 USER78
DATA
Acceptable values for AllFusion CA-Librarian:
ASM JCL
COB PLF
DAT PL/1
FOR RPG
FRG TXT
GIS VSB
GOF
Notes:
If you plan to use in-stream data in processors, for
type Process, specify in this field:
1. DATA for AllFusion CA-Panvalet
2. 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.

Chapter 2. Defining Inventory Structures 2-35

2.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. 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 is 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.
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).
WS HOME OPSYS Indicates the platform where the elements of this type are

1 created. Acceptable values are:
■ W — Workstation
■ M — Mainframe

2-36 Administration Guide

 2.7 Defining Types

Field Description
WS File Ext
1 Indicates the 1- to 3-character file extension used on the
workstation or LAN platforms for elements of this type.
Note:

1: These fields are displayed for E-Link users only.

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

2.7.6.4 Libraries

These library names can be specified using symbolics. Available symbolics are
described in 2.7.10, “Using Symbolics to Define Base and Delta Libraries” on
page 2-40.

Field Description
Base/Image Library Name of the base library for the type. Can be PDS,
(Required) AllFusion CA-Panvalet, AllFusion CA-Librarian, or
Endevor LIB.
Delta Library Name of the delta library for the type. Can be PDS,
(Required) AllFusion CA-Panvalet, AllFusion CA-Librarian, or
Endevor LIB.

Chapter 2. Defining Inventory Structures 2-37

2.7 Defining Types

Field Description
INCLUDE Library Name of the PDS, ELIB, AllFusion CA-Panvalet, or
(Optional) 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 Output Library Data set name of source output library.
(Optional)
Expand Includes Indicates whether Include statements are expanded when
(Optional) the element is written to the source output library.
Acceptable values are:
■ Y — Expand Include statements.
■ N — Do not expand Include statements.

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

2.7.8 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

2-38 Administration Guide

 2.7 Defining Types

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

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

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

Chapter 2. Defining Inventory Structures 2-39

2.7 Defining Types

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

2.7.10 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 or this alias

symbolic
Site &C1SITE
Environment &C1ENVMNT &C1EN
Stage &C1STAGE &C1ST
Stage 1 &C1STAGE1 &C1ST1
Stage 2 &C1STAGE2 &C1ST2
Stage ID &C1STGID &C1SI
Stage 1 ID &C1STGID1 &C1SI1
Stage 2 ID &C1STGID2 &C1SI2
Stage number &C1STGNUM &C1S#
System &C1SYSTEM &C1SY
Subsystem &C1SUBSYS &C1SU
Type &C1ELTYPE &C1TY

2-40 Administration Guide

 2.7 Defining Types

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.

Chapter 2. Defining Inventory Structures 2-41

2.8 Defining the Type Processing Sequence

2.8 Defining the Type Processing Sequence

To define the relative sequence of processing for the various element types defined
within a 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 2.7, “Defining Types” on page 2-29, 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.

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

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


OPTION ===>

blank - Display type processing sequence

U - Update type processing sequence

ENVIRONMENT ===> SMPLTEST

SYSTEM ===> ADMIN

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

 

2.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).
2. Enter an environment name, if different from the displayed name.
3. Enter a system name or mask.
4. Enter a stage ID.
5. Press ENTER.
■ If Endevor displays a System Selection List, select a system, press 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.

2-42 Administration Guide

 2.8 Defining the Type Processing Sequence

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

2.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 --------------- TYPE PROCESSING SEQUENCE ----------- Row 1 to 2 of 2


COMMAND ===> SCROLL ===> CSR

CURRENT ENV: SMPLTEST STAGE ID: Q SYSTEM: ADMIN

NEXT ENV: SMPLPROD STAGE ID: P SYSTEM: ADMIN

UPDATED: 23OCT2 17:9 BY CHARPER

RELATIVE
PROCESSING TYPE DESCRIPTION
SEQUENCE
1 PROCESS ENDEVOR PROCESSOR DEFINITIONS
2 COBOL Cobol Source Code
 Bottom of data 

 

Chapter 2. Defining Inventory Structures 2-43

2.8 Defining the Type Processing Sequence

2.8.3.1 Type Processing Sequence Panel Fields

Panel fields are described below. All fields but RELATIVE PROCESSING
SEQUENCE are display-only.

Field Description
Current Env Name of the current environment.
Stage ID ID of the current stage.
System Name of the current system.
Next Env Name of the environment at the next map location.
Next Stage ID ID of the first stage at the next map location.
Next System Name of the current system at the next map location.
Updated Identifies the date, time, and user ID of the last user to
update the processing sequence definition. When creating
a new type processing sequence this field is blank.

2-44 Administration Guide

 2.8 Defining the Type Processing Sequence

Field Description
Relative Processing A 3-digit number that defines the relative processing order
Sequence 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 CLISTS
■ 020 JCL
■ 030 PROC
■ 040 COPYBOOK
You decide that you want to run JCL after PROC. You
can reorder the processors by typing over 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.

Chapter 2. Defining Inventory Structures 2-45

2.9 Updating Type Data Set Definitions

2.9 Updating Type Data Set Definitions

2.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 Sets
Request panel.

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


OPTION ===>

blank - Display type data sets

U - Update type data sets

ENVIRONMENT ===> SMPLTEST

SYSTEM ===> ADMIN

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

 

2.9.2 Procedure: Type Data Set Definitions

From the Type Data Set Request panel, follow this procedure to view/change the name
of one or more data sets defined for a system:
1. Select an option (Blank or U).
2. Enter an environment name, if different from the displayed name.
3. Enter a system name or mask.
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.

2-46 Administration Guide

 2.9 Updating Type Data Set Definitions

2.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 ---------------------- TYPE DATA SETS -------------- Row 1 to 3 of 3


COMMAND ===> SCROLL ===> CSR

CURRENT ENV: SMPLTEST STAGE ID: Q SYSTEM: ADMIN

NEXT ENV: SMPLTEST STAGE ID: Q SYSTEM: ADMIN

DATA SET NAME --- LAST MODIFIED ---

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

The following list describes the panel fields. All fields but DATA SET NAME are
display-only.

Field Description
Current Env Name of the current environment.
(Current) Stage ID ID of the current stage.
(Current) System Name of the current system.
Next Env Name of the environment at the next map location.
(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.

Chapter 2. Defining Inventory Structures 2-47

2.9 Updating Type Data Set Definitions

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.

2-48 Administration Guide

 2.10 Displaying Environment Information

2.10 Displaying Environment Information

2.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. (For more information on the definition process, see the Installation
Guide.)

 -------------------------- Environment Information ---------------------------- 

Command ===>

Current Environment,...... SMPLTEST

Title..................... SAMPLE TEST ENVIRONMENT
Next Environment.......... SMPLPROD

User Security Table.......

Resource Security Table...
Journal................... (NONE)
SMF Activity.............. N
SMF Security.............. N
MVS/DB Bridge............. N
 
To return to the Environment Options Menu, press END.

2.10.1.1 Environment Information Panel Fields

The following list describes the panel fields. All fields except for CURRENT
ENVIRONMENT are display-only.

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 Name of the next environment on the map.
User Security Table Name of the User Security Table currently in use.
1
Resource Security Name of the Resource Security Table currently in use.
1
Table
Journal Applicable only to users of Endevor's Point in Time
Recovery facility. Name of the journal file used by this
facility.

Chapter 2. Defining Inventory Structures 2-49

2.10 Displaying Environment Information

Field Description
SMF Activity Indicates whether the SMF facility is active for this
environment: Y or N
2
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

2-50 Administration Guide

Chapter 3. Mapping

Chapter 3. Mapping 3-1

3.1 What Is a Map?

3.1 What Is a Map?

3.1.1 Overview
Part of implementing Endevor is to define the stages in the software life cycles at your
site, then organize these stages into environments. The Overview 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:

3-2 Administration Guide

 3.1 What Is a Map?

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

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

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

Chapter 3. Mapping 3-3

3.1 What Is a Map?

For more information on modifying the Defaults Table to create map routes, see the
Installation Guide.

3.1.4 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 and/or environments.

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 DEV QA QA PROD PROD

UNIT INT QA HOLD FIX PROD
NEXT FINANCE FINANCE FINANCE FINANCE NONE NONE
SYSTEM
NEXT PO PO PO PO NONE NONE
SUBSYSTEM
NEXT BTCHCOB BTCHCOB BTCHCOB BTCHCOB N/A NONE
GROUP
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 2, “Defining Inventory
Structures” (system and subsystem definitions) and the Extended Processors Guide
(processor group definition).

3-4 Administration Guide

 3.2 Design Strategies and Guidelines

3.2 Design Strategies and Guidelines

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

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

Chapter 3. Mapping 3-5

3.2 Design Strategies and Guidelines

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

3-6 Administration Guide

 3.2 Design Strategies and Guidelines

3.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 QA PROD PROD

HOLD FIX PROD
NEXT FINANCE FINANCE FINANCE FINANCE NONE NONE
SYSTEM (on system BILL (on system BILL
and system MARY and system MARY
definition panels) definition panels)
NEXT PO PO PO PO NONE NONE
SUBSYSTEM
NEXT BTCHCOB BTCHCOB BTCHCOB BTCHCOB N/A NONE
GROUP

Chapter 3. Mapping 3-7

3.2 Design Strategies and Guidelines

This route looks like this:

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

3-8 Administration Guide

Chapter 4. Site Symbolics

Chapter 4. Site Symbolics 4-1

4.1 Site-Defined Symbolics

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

4-2 Administration Guide

 4.2 Site Symbolics Overview

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

4.2.1 Defining Site Symbolics

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

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.

Chapter 4. Site Symbolics 4-3

4.2 Site Symbolics Overview

Use the JCL member contained in member BC1JSYMT to create the site symbolics
table.

4.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, X
SYMBOLTBL=ESYMBOLS, X
SYSIEWL=SYSIEWLP, X
MIXEDFMT=(DESCRIPTION,COMMENT), X
UIDLOC=(1,7), X
VIOUNIT=VIO, X
WRKUNIT=SYSDA, X
RACFUID=NDVUSER, X
RACFGRP=NDVALT, X
PKGCSEC=N, X
PKGCVAL=O, X
PKGSEC=ESI, X
PRBLKSZ=, X
PRLNKSZ=(896K,96K), X
PRLSTSZ=1, X
MODHLI=CA
C1DEFLTS TYPE=ENVRNMNT, X
ENVNAME=TSTSMPL X
ENVTITL='Endevor Administraion Application'. X

The Site Information from C1DEFLTS panel displays the parameter value in the
SYMBOLICS Table field.

 ---------------------- 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-LSERV JRNL SBS. ELINK XLTE TBL....
PITR Journal Grp.. Mixed Format...... CCID COMMENT DESCRIPTION
SYMBOLICS Table...
(Press Enter for Next Panel)
 
These are the site symbolics defined in your system.

4-4 Administration Guide

 4.2 Site Symbolics Overview

 DISPLAY ---------------- SYMBOL TABLE: ESYMBOLS ------------ Row 1 to 6 of 6


COMMAND ===> SCROLL ===> CSR

SYMBOL VALUE
------------ ------------------------------------------------------------------
#ENDEVOR CA.Software.Endevor
#PERMBASE1 /u/endevor/sampltest/admin/base
 Bottom of data 
 

Chapter 4. Site Symbolics 4-5

4-6 Administration 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 it 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 it in each environment in which it appears.

5-2 Administration Guide

 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, governs 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) The same element name exists within another subsystem under the
same system; the action is performed and a caution message is
issued.
W (Warning) The same element name exists within another subsystem under the
same system; the action is performed and a warning message is
issued.

The System Definition panel displays the parameter values in the Duplicate Element
Name Check and Msg Severity Lvl fields highlighted below.

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


COMMAND ===>

CURRENT ENV: SMPLTEST NEXT ENV: SMPLPROD

SYSTEM: FINANCE NEXT SYSTEM ===> FINANCE
SYSTEM TITLE ===> FINANCIAL 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 LIBRARIES:

STAGE 1 LOAD LIBRARY ===> CA.ENDEVOR.SMPLEMER.PRCSLOAD
STAGE 1 LIST LIBRARY ===> CA.ENDEVOR.SMPLEMER.PRCSLIST
STAGE 2 LOAD LIBRARY ===> CA.ENDEVOR.SMPLPROD.PRCSLOAD
STAGE 2 LIST LIBRARY ===> CA.ENDEVOR.SMPLPROD.PRCSLIST
 

Chapter 5. Element Registration 5-3

5.3 Controlling Duplicate Element Names at the Processor Group Level

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

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

5-4 Administration Guide

 5.3 Controlling Duplicate Element Names at the Processor Group Level

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


COMMAND ===>

CURRENT ENV: SMPLTEST NEXT ENV: SMPLPROD

SYSTEM: FINANCE NEXT SYSTEM ===> FINANCE
SYSTEM TITLE ===> FINANCIAL 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 LIBRARIES:

STAGE 1 LOAD LIBRARY ===> CA.ENDEVOR.SMPLEMER.PRCSLOAD
STAGE 1 LIST LIBRARY ===> CA.ENDEVOR.SMPLEMER.PRCSLIST
STAGE 2 LOAD LIBRARY ===> CA.ENDEVOR.SMPLPROD.PRCSLOAD
STAGE 2 LIST LIBRARY ===> CA.ENDEVOR.SMPLPROD.PRCSLIST
 

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: SMPLTEST STAGE ID: Q SYSTEM: ADMIN TYPE: COBOL

NEXT ENV: SMPLPROD STAGE ID: P SYSTEM: ADMIN TYPE: COBOL

PROCESSOR GROUP: CLENBL PROCESSOR O/P TYPE ===> LOADMODULE

DESCRIPTION ===> COBOL/LE COMPILE AND LINK, LISTING IS STORED
NEXT PRCS GROUP ===> CLENBL

UPDATED: BY

----------------------- OUTPUT MANAGEMENT INFORMATION -----------------------

PROCESSOR TO USE FOR MOVE ACTION ===> M (M/G)

PROCESSOR TO USE FOR TRANSFER ACTION ===> G (M/G)

S - Browse Symbolics L - List Processor

U - Update Symbolics
FOREGROUND EXECUTION
GENERATE PROCESSOR ===> GCIINBL ===> Y (Y/N)
DELETE PROCESSOR ===> DLODNNL ===> Y (Y/N)
MOVE PROCESSOR ===> MLODNNL ===> Y (Y/N)

 

Chapter 5. Element Registration 5-5

5.3 Controlling Duplicate Element Names at the Processor Group Level

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.

5-6 Administration Guide

Chapter 6. Using CCIDs

Chapter 6. Using CCIDs 6-1

6.1 Overview

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

6-2 Administration Guide

 6.2 What CCIDs and/or Comments Indicate

6.2 What CCIDs and/or Comments Indicate

6.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 The CCID and/or comment used the last time any action
and/or comment 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 The CCID and/or comment used the last time an Endevor
and/or comment action changed the source. This CCID and/or comment is
stored in the Master Control File.
Generate CCID and/or The CCID and/or comment used the last time an Endevor
comment 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 These fields only reflect the CCID and/or comment used
comment 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 Each delta level contains the CCID and/or comment
and/or comment specified in the action that created the delta level.
Component List Delta Each component list delta level contains the CCID and/or
CCID and/or comment comment specified in the action that created the delta
level.

Chapter 6. Using CCIDs 6-3

6.3 Requiring CCIDs

6.3 Requiring CCIDs

6.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 -------------------- SYSTEM DEFINITION --------------------------------


COMMAND ===>

CURRENT ENV: SMPLTEST NEXT ENV: SMPLPROD

SYSTEM: FINANCE NEXT SYSTEM ===> FINANCE
SYSTEM TITLE ===> FINANCIAL APPLICATIONS
UPDATED: 15OCT2 14:3 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 LIBRARIES:

STAGE 1 LOAD LIBRARY ===> CA.ENDEVOR.SMPLEMER.PRCSLOAD
STAGE 1 LIST LIBRARY ===> CA.ENDEVOR.SMPLEMER.PRCSLIST
STAGE 2 LOAD LIBRARY ===> CA.ENDEVOR.SMPLPROD.PRCSLOAD
STAGE 2 LIST LIBRARY ===> CA.ENDEVOR.SMPLPROD.PRCSLIST
 
3. Enter Y in the CCID and/or COMMENT fields, and press ENTER to save your
changes.

6-4 Administration Guide

 6.3 Requiring CCIDs

6.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 Element: FAPCOB1

Environment: SMPLTEST System: ADMIN Subsystem: ACCTPAY

Type: COBOL Stage: TEST

CCID ===>
COMMENT ===>

 
To complete your action request, type a valid CCID and/or comment on this screen
and press ENTER.

Chapter 6. Using CCIDs 6-5

6.4 When Endevor Updates CCID Fields

6.4 When Endevor Updates CCID Fields

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

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

6-6 Administration Guide

 6.4 When Endevor Updates CCID Fields

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

6.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:
■ Set the LAST ACTION CCID and/or COMMENT fields.
■ Set the CURRENT SOURCE and SOURCE DELTA CCID and/or 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.

6.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:
■ Set the LAST ACTION CCID and/or COMMENT fields.
■ Set the CURRENT SOURCE and SOURCE DELTA CCID and/or COMMENT
fields if the element has changed.
■ Set the GENERATE CCID and/or COMMENT fields if the generate processor is
run.

Chapter 6. Using CCIDs 6-7

6.4 When Endevor Updates CCID Fields

■ 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
action will not set the generate or component list delta CCID and/or COMMENT
fields.

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

6.4.5 Generate Action CCID Updates

When you specify a CCID and/or comment in a GENERATE action, Endevor updates
CCID and/or COMMENT fields differently depending on whether you specify the
GENERATE action with or without copyback.

6.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 LAST ACTION CCID and/or COMMENT fields.
■ 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.

6.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.
■ Set the GENERATE and COMPONENT LIST DELTA CCID and/or 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.

6-8 Administration Guide

 6.4 When Endevor Updates CCID Fields

6.4.6 Move Action CCID Updates

When you specify a CCID and/or comment in a MOVE action, Endevor updates CCID
and/or COMMENT fields differently depending on whether you specify the MOVE
action with history or without history.

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

6.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.
■ Clears the RETRIEVE CCID and/or COMMENT fields.

6.4.7 Transfer Action CCID Updates

When you specify a CCID and/or comment in a TRANSFER action, Endevor updates
CCID and/or COMMENT fields differently depending on whether you specify the
TRANSFER request without history, with history, or with synchronization.

6.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:
■ Set the LAST ACTION CCID and/or COMMENT fields.
■ Set the GENERATE and COMPONENT LIST DELTA CCID and/or COMMENT
fields if the generate processor is run.

Chapter 6. Using CCIDs 6-9

6.4 When Endevor Updates CCID Fields

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.
■ Clears the RETRIEVE CCID and/or COMMENT fields.

6.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:
■ Set the LAST ACTION CCID and/or COMMENT fields.
■ Set the GENERATE and COMPONENT LIST DELTA CCID and/or COMMENT
fields if the generate processor is run.

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.
■ Clears the RETRIEVE CCID and/or COMMENT fields.

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.

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

6-10 Administration Guide

 6.4 When Endevor Updates CCID Fields

6.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:
■ Set the LAST ACTION CCID and/or COMMENT fields.
■ Set the GENERATE and COMPONENT LIST DELTA CCID and/or COMMENT
fields if the generate processor is run.

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
action will not set the generate or component list delta CCID and/or COMMENT
fields.

6.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 Generate Last Retrieve Source Delta Component CCID/

Source CCID/ Action CCID/ CCID/ Comment Comment
CCID/ Comment CCID/ Comment
Comment Comment
Add (new Set Set if Set Set Set if generated
element) changed
Add Set if Set if Set Set Set if generate
(existing changed generated creates a delta
element)
Update Set if Set if Set Set if changed Set if generate
changed generated creates a delta
Retrieve Set
Generate Set Set Set if generate
without creates a delta
copyback
Generate Set to Set Set Set to copied back Set
with copied value
copyback back
value
Signin Clear

Chapter 6. Using CCIDs 6-11

6.4 When Endevor Updates CCID Fields

Action Current Generate Last Retrieve Source Delta Component CCID/

Source CCID/ Action CCID/ CCID/ Comment Comment
CCID/ Comment CCID/ Comment
Comment Comment
Delete
Restore Set from Set if Set Set Set from Archive Set if generated
Archive generated from
Archive
Archive
Move Set from Set from Set Clear Set from last start Set from last start
without start start location delta value location delta value
history location location
value value
Move with Set from Set from Set Clear Carried with delta Carried with delta
history start start levels levels
location location
value value
Transfer Set from Set if Set Clear Set from last delta Set if generated
without previous generated value previous
history stage stage
value
Transfer Set from Set if Set Clear Carried with delta Set if generated
with previous generated levels
history stage
value
Transfer Set from Set if Set Clear Set from base Set if generated
with SYNC previous generated value. Carried with
stage delta levels + on
value SYNC level

6-12 Administration Guide

 6.5 Predefining CCIDs

6.5 Predefining CCIDs

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

6.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
Information/Management Administration Guide for more information.

Chapter 6. Using CCIDs 6-13

6.5 Predefining CCIDs

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

6.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 Installation Guide.

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

6-14 Administration Guide

 6.5 Predefining CCIDs

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

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

* * * ** * * *

3 16 25 34 36 45 54 63

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

Chapter 6. Using CCIDs 6-15

6.5 Predefining CCIDs

■ Systems for TAX-CHNG-89 = PAYROLL and ACCOUNTG

■ Systems for NEW-COMPPLAN = PAYROLL and PERSONEL

The CCID definition file would be coded as:

card
position 3 16 25 34 36 45 54 63
 CCID USERID ENVIRON # SYSTEM SUBSYS TYPE ELEMENT
TAX-CHNG-89 DEV DEMO 1 PAYROLL
TAX-CHNG-89 DEV DEMO 1 ACCOUNTG
NEW-COMPPLAN DEV DEMO 1 PAYROLL
NEW-COMPPLAN DEV DEMO 1 PERSONEL

6.5.4.1 Sample CCID Definition Data Set

A sample CCID definition data set is provided below.

card
position 3 16 25 34 36 45 54 63
 CCID USERID ENVIRON # SYSTEM SUBSYS TYPE ELEMENT
AC-DEV-89/2 ZSXBAP1 DEMO 1 ACCOUNTG
MA-DEV-89/2 ZSX DEMO 1 MANUFACT
PE-DEV-89/2 ZSXJMH1 DEMO 1 PERSONEL
PE-DEV-89/2 ZSXPGM1 DEMO 1 PERSONEL
PE-DEV-89/2 ZSXSXV1 DEMO 1 PERSONEL
QA-89/2 ZSXREL1 DEMO 2    
EMERGNCY-FIX 2

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.

6-16 Administration Guide

 6.5 Predefining CCIDs

Field Card Description

Position
CCID 3 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 updated under
the CCID indicated on this 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 updated under
the CCID indicated on this line.
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 6. Using CCIDs 6-17

6-18 Administration Guide
Chapter 7. SMF Recording

Chapter 7. SMF Recording 7-1

7.1 Overview

7.1 Overview

7.1.1 SMF Function

If the SMF interface is implemented at your site (as described in the Installation
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 Exits 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
Installation Guide.

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

7-2 Administration Guide

 7.2 Record Formats

7.2 Record Formats

7.2.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 7.3, “DSECT Descriptions” on page 7-6.

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

7.2.3 SMF Action Records

SMF Action Records include data specific to the action being reported, and apply for
all actions except SIGNIN, 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 7.3.5, “$SMFBKDS DSECT: Action-Specific Blocks” on
page 7-13.

Chapter 7. SMF Recording 7-3

7.2 Record Formats

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)

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 DSECT Type Actions Description

Block
Detail
Type #
1 Environment Add (2) Information describing the
(SM2ENVDS) Update (2) environment where the action took
Retrieve (2) place: name of the environment,
Generate site ID, etc. Where two blocks are
Move(2) used, one represents the source
Delete environment for the element, while
Transfer (2) the other represents the target
Archive (2) environment.
Restore (2)
2 Last Change Add Information describing the last
(SM2LCGDS) Update action (the action being recorded):
Generate date and time of the action,
Move comments describing the action, and
Delete so forth.
Transfer
Restore
3 Processor Info Add Information about the last processor
(SM2LPRDS) Update executed: processor name, date and
Generate time of execution, etc. Used for
Move actions that can invoke a processor.
Delete
Transfer
Restore

7-4 Administration Guide

 7.2 Record Formats

Action DSECT Type Actions Description

Block
Detail
Type #
4 Request All actions General information about the
Parameter action: CCID, comments, and so
Info forth.
(SM2REQDS)

Chapter 7. SMF Recording 7-5

7.3 DSECT Descriptions

7.3 DSECT Descriptions

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

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

7-6 Administration Guide

 7.3 DSECT Descriptions

$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
DS D
SMHSIZE EQU -$SMFHDDS SIZE OF THE HEADER ( FOR SMHHDLEN)
SMHDATA EQU  START OF THE DATA
MEND

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

Chapter 7. SMF Recording 7-7

7.3 DSECT Descriptions

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

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

7-8 Administration Guide

 7.3 DSECT Descriptions

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

Chapter 7. SMF Recording 7-9

7.3 DSECT Descriptions

7.3.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 Exits 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 Exits
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.
SM1ERRLN Not used.
SM1ERMSG Error message associated with the current activity, as
described in Chapter 9, “Performance and Tuning” for the
ECBMSG field.
SM1SITE Endevor site ID, as defined to the Defaults Table.
SM1STGID Stage number for the current action request: 1 or 2.
SM1STGCD Applicable if SM1FUNC references an Endevor 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 Exits Guide.
SM1ENVM Environment name for the current processing.
SM1STAGE Applicable if SM1FUNC references an Endevor action.
Stage name for the current action request.
SM1SYSTM Applicable if SM1FUNC references an Endevor action.
System name for the current action.

7-10 Administration Guide

 7.3 DSECT Descriptions

Field Description
SM1SUBSY Applicable if SM1FUNC references an Endevor action.
Subsystem name for the current action.
SM1STYPE Applicable if SM1FUNC references an Endevor action.
Element type for the current action.
SM1ELEMT
1 Applicable if SM1FUNC references an Endevor 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.
SM1FAOFF
2 File 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 file area is comprised
of two adjacent components:
■ Two byte field containing the length
■ 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
beginning of the record's address, the resulting address
points to an area with in the SM1BFAREA. The name
area consists of two adjacent components:
■ Two byte field containing the length
■ File name
The name may be a member name or an HFS 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.

Chapter 7. SMF Recording 7-11

7.3 DSECT Descriptions

Field Description
SM1SIZ Size of the $SMFREC1 DSECT.
Note:

1: Version 1 records only

2: Version 2 records only

7.3.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 7.3.5, “$SMFBKDS DSECT: Action-Specific
Blocks” on page 7-13.
$SMFREC2
$SMFREC2 DSECT
$SMFREC2 DS D ALIGN IT

 
 $SMFREC2 - DESCRIPTION FOR THE ACTIVITY RECORD 
 

SM2REC1 EQU  START OF THE SMF 2 RECORD
SM2RECLN DS H LENGTH OF THE ACTIVITY RECORD
SM2RECVN DS H VERSION OF THE RECORD
SM2$V1 EQU X'1' VERSION 1
SM2$CURV EQU SM2$V1 CURRENT VERSION 1
SM2FUNC DS F ACTION CODE
 SEE ECBFUNC OF $ECBDS FOR LIST OF
 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
 SEE ECBFUNC OF $ECBDS FOR LIST OF
 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

7-12 Administration Guide

 7.3 DSECT Descriptions

MEND

7.3.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 Exits Guide.
SM2FUNNM Applicable if SM2FUNC references an Endevor 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 Exits 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.

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

Chapter 7. SMF Recording 7-13

7.3 DSECT Descriptions

 
 EACH BLOCK IS PRECEDED BY A HEADER: 
 TYPE 1 - ENVIRONMENT INFORMATION 
 TYPE 2 - LAST CHANGE INFORMATION 
 TYPE 3 - PROCESSOR INFORMATION 
 TYPE 4 - REQUEST PARAMETER INFORMATION 

 
 BLOCK HEADER 
 

AIF ('&DSCT' NE 'YES').NODSCT
SM2BHDDS DSECT
AGO .START
.NODSCT ANOP
SM2BHDDS DS D ALIGN IT
.START ANOP
SM2BLEN DS H LENGTH OF THE BLOCK
SM2BTYP DS H TYPE OF BLOCK
SM2BVER DS H VERSION OF BLOCK
SM2B$V1 EQU 1 VERSION 1
SM2B$V2 EQU 2 VERSION 2
SM2BFLG1 DS CL1 FLAG 1 FOR BLOCK
SM2BFLG2 DS CL1 FLAG 2 FOR BLOCK
DS D
SM2BHDR EQU -SM2BHDDS LENGTH OF HEADER

 
 ENVIRONMENT BLOCK TYPE 1 
 

AIF ('&DSCT' NE 'YES').NODSCT1
SM2ENVDS DSECT
AGO .START1
.NODSCT1 ANOP
SM2ENVDS DS D ALIGN IT
.START1 ANOP
DS D  START OF HEADER
SM2ELEN DS H LENGTH OF THE BLOCK
SM2ETYP DS H TYPE OF BLOCK
SM2EVER DS H VERSION OF BLOCK (SM2B$V1/V2)
SM2EFLG1 DS CL1 FLAG 1 FOR BLOCK
SM2EFLG2 DS CL1 FLAG 2 FOR BLOCK
DS D  END OF HEADER
SM2SITE DS CL1 SITE CODE
SM2STGCD DS CL1 STAGE SELECTION CODE FROM C1DEFLTS
SM2STGID DS XL1 STAGE ID - 1 OR 2
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

7-14 Administration Guide

 7.3 DSECT Descriptions

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 ('&DSCT' NE 'YES').NODSCT2
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
SM2LTYP DS H TYPE OF BLOCK
SM2LVER DS H VERSION OF BLOCK (SM2B$V1)
SM2LFLG1 DS CL1 FLAG 1 FOR BLOCK
SM2LFLG2 DS CL1 FLAG 2 FOR BLOCK
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

 

Chapter 7. SMF Recording 7-15

7.3 DSECT Descriptions

 PROCESSOR INFO BLOCK TYPE 3 

 

AIF ('&DSCT' NE 'YES').NODSCT3
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 ('&DSCT' NE 'YES').NODSCT4
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 DS H TYPE OF BLOCK
SM2RVER DS H VERSION OF BLOCK
SM2R2 EQU  RELEASE 2.2 FORMAT THRU RELEASE 3.
SM2R35 EQU 1 RELEASE 3.5 FORMAT
SM2CREL EQU 1 CURRENT RECORD FORMAT VERSION
SM2RFLG1 DS CL1 FLAG 1 FOR BLOCK
SM2RFLG2 DS CL1 FLAG 2 FOR BLOCK
DS D  END OF HEADER
SM2RCCID DC CL12' ' CCID ASSOC W/ ACTION
SM2RCOMM DC CL4' ' COMMENT ASSOC W/ ACTION
SM2RFLAG DC F'' ANY SPECIAL FLAGS
SM2RSISO DC CL1' ' SIGNIN/SIGNOUT FORCE ( Y OR N)
SM2RSICO DC CL1' ' SIGNIN/SIGNOUT COPY ONLY ( Y OR N)
SM2REXPN DC CL1' ' EXPAND INCLUDES ( Y OR N)
SM2ROVER DC CL1' ' WRITE OVER EXISTING RETR MBR
SM2RRTCD DC F'' ACTION RETURN CODE

7-16 Administration Guide

 7.3 DSECT Descriptions

SM2RDEL DC CL1' ' DELETE REQUEST FLAG

 BLANK IF N/A
 Y - YES, DELETE WAS REQUESTED
 N - NO, DELETE WAS NOT REQUESTED
SM2RIGNF DC CL1' ' IGNORE GENERATE FAILED (Y / N)
SM2RBGNP DC CL1' ' BYPASS GENERATE PROCESSOR (Y / N)
SM2RBDLP DC CL1' ' BYPASS DELETE PROCESSOR (Y / N)
SM2RSYNC DC CL1' ' SYNC OPTION SPECIFIED (Y / N)
SM2RONCP DC CL1' ' DELETE ONLY COMPONENTS (Y / N)
SM2RMVWH DC CL1' ' MOVE/TRANSFER W/ HISTORY (Y / N)
SM2RAWUP DC CL1' ' ADD W/ UPDATE OPTION (Y / N)
SM2RPGRP DC CL8' ' PROCESSOUR GROUP OVERRIDE
SM2RSIUS DC CL8' ' SIGNOUT TO USERID
SM2RDATA DS D
SM2REQLN EQU -SM2REQDS LENGTH OF PROCESS BLOCK
MEND

7.3.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.
SM2BHDR Size of the action-block header ($SM2BHDDS).

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

Chapter 7. SMF Recording 7-17

7.3 DSECT Descriptions

Field Description
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.
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:
■ Two-byte length field
■ 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.

7-18 Administration Guide

 7.3 DSECT Descriptions

Field Description
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:
■ Two-byte length field
■ 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

7.3.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 Size of the action-specific block (header and detail) if the
action-block detail uses the Last Change DSECT
($SM2LCGDS).

Chapter 7. SMF Recording 7-19

7.3 DSECT Descriptions

7.3.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 Size of the action-specific block (header and detail) if the
action-block detail uses the Processor Information DSECT
($SM2LPRDS).

7.3.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
SM2RSICO Applicable for a RETRIEVE action. Indicates whether the
current action specified copy-only: Y or N
1
SM2REXPN Applicable for a RETRIEVE action. Indicates whether the
current action requested that INCLUDEs be expanded: Y
or N
1
SM2ROVER Applicable for a RETRIEVE action. Indicates whether 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.

7-20 Administration Guide

 7.3 DSECT Descriptions

Field Description
SM2REQLN Size of the action-specific block (header and detail) if the
action-block detail uses the Request Parameter Information
DSECT ($SM2REQDS).
Note:

1:Y — Yes; N — No

Chapter 7. SMF Recording 7-21

7-22 Administration Guide
Chapter 8. The User Options Menu Facility

Chapter 8. The User Options Menu Facility 8-1

8.1 Overview

8.1 Overview

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

2 ACMQ - Endevor ACM Query Facility

Enter END to return to the Endevor Primary Options Menu

 
The User Options Menu is delivered as member NDVRUSER in 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.

8-2 Administration Guide

 8.2 User Option Menu Panel Overview

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

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

Chapter 8. The User Options Menu Facility 8-3

8.2 User Option Menu Panel Overview

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

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

8-4 Administration Guide

 8.2 User Option Menu Panel Overview

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 8. The User Options Menu Facility 8-5

8-6 Administration Guide
Chapter 9. Performance and Tuning

Chapter 9. Performance and Tuning 9-1

9.1 Overview

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

9-2 Administration Guide

 9.2 Choosing Between Delta Formats

9.2 Choosing Between Delta Formats

9.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 I/O Use for elements that:

operations operations
needed — needed —
Read Write
Forward 2 1 ■ Are updated more than they are
read.
■ Are in production.
Reverse 1 2 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.

Chapter 9. Performance and Tuning 9-3

9.2 Choosing Between Delta Formats

9.2.2 Converting from Forward to Reverse Deltas

For details about the conversion process, see Appendix A, “Converting Delta
Formats.”

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

9-4 Administration Guide

 9.3 Setting the Element Delta Consolidation Level

9.3 Setting the Element Delta Consolidation Level

9.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 97
- LVLS TO CONSOL - 25
Minimum level 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 2.7.4,
“Type Definition Panel” on page 2-31.

Chapter 9. Performance and Tuning 9-5

9.4 Mapping Multiple Environments

9.4 Mapping Multiple Environments

9.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 Stage 1. 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 3, “Mapping”

9-6 Administration Guide

 9.5 Selecting a Library Type for Base and Delta Members

9.5 Selecting a Library Type for Base and Delta Members

9.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 ■ Directory overhead
standard means of storage becomes inefficient if there
for the source. are more than 3-4K+
■ No installation issues. members.
■ Members can be read by ■ Strict maintenance is
other utilities such as required to prevent x37
compilers. abends.
PDS/E ■ Low maintenance. ■ Benchmarks show that the
■ Current technology. performance is slower than
■ Members can be read by PDS or Endevor LIB.
other utilities such as ■ Does not allow EXCP
compilers. processing.
Endevor LIB ■ Low maintenance. ■ VSAM options can require
■ Sophisticated set of a lot of processing time.
utilities to manage the ■ Utilities are required for
data sets. expands, copies, etc.
■ BDAM is more efficient ■ Library members accessible
for medium-sized only through Endevor.
directories, and VSAM is ■ Multiple volume ELIBs are
more efficient for large not supported.
directories, than either
PDS or PDS/E.
■ Directory overhead
routines are designed for
a large number of
members, thereby
increasing efficiency.

Chapter 9. Performance and Tuning 9-7

9.5 Selecting a Library Type for Base and Delta Members

Medium Benefits Drawbacks

AllFusion ■ Accommodates the site ■ With AllFusion
CA-Panvalet/AllFusion standard. CA-Panvalet, conflicts arise
CA-Librarian ■ Directory compression with Endevor footprint and
issues are eliminated. comment information.
■ Source output file can be ■ Library members are only
read directly by accessible through
AllFusion CA-Panvalet/ AllFusion CA-Panvalet
AllFusion CA-Librarian and/or AllFusion
utilities. CA-Librarian.

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

9-8 Administration Guide

 9.6 Using L-Serv for Endevor's VSAM File Processing

9.6 Using L-Serv for Endevor's VSAM File Processing

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

9.6.2 Setting the RECBUFFSIZE Parameter

When you install L-Serv, set the RECBUFFSIZE parameter based on your site's
configuration. If you are using 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.

9.6.3 Monitoring 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 L-Serv's monitoring facilities, see the Unicenter Common Services
CA-L-Serv Technical Bulletin.

Chapter 9. Performance and Tuning 9-9

9.6 Using L-Serv for Endevor's VSAM File Processing

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

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

9-10 Administration Guide

 9.7 Using OS/390 SYSPLEX VSAM Record Level Sharing (RLS) Support for MCFs and Package Data Set

9.7 Using OS/390 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 OS/390 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
OS/390 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:

■ 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

Chapter 9. Performance and Tuning 9-11

9.7 Using OS/390 SYSPLEX VSAM Record Level Sharing (RLS) Support for MCFs and Package Data Set

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

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

9-12 Administration Guide

 9.8 Tuning Your Processors

9.8 Tuning Your Processors

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

Chapter 9. Performance and Tuning 9-13

9.9 Tuning Your System

9.9 Tuning Your System

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

9-14 Administration Guide

Appendix A. Converting Delta Formats

Appendix A. Converting Delta Formats A-1

A.1 Steps for Converting Forward to Reverse Delta

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.

A-2 Administration Guide

 A.1 Steps for Converting Forward to Reverse Delta

Types that can benefit from the reverse delta storage format include:
■ Copybooks
■ JCL
■ Source

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.

Appendix A. Converting Delta Formats A-3

A.1 Steps for Converting Forward to Reverse Delta

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 ----------------------- TYPE DEFINITION -------------------------------


COMMAND ===>

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

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

DESCRIPTION ===> Cobol Source Code

UPDATED: BY
----------------- ELEMENT OPTIONS -------------------
FWD/REV/IMG DELTA ===> R (F/R/I) COMPRESS BASE/ENCRYPT NAME ===> Y (Y/N)
DFLT PROC GRP ===> CLENBL REGRESSION PCT ===> 75 REGR SEV ===> W (I/W/C/E)
SOURCE LENGTH ===> 8
COMPARE FROM ===> 7 COMPARE TO ===> 72
AUTO CONSOL ===> Y (Y/N) LANGUAGE ===> cobol PV/LB LANG ===> DATA
CONSOL AT LVL ===> 96 HFS RECFM ===> NL (COMP/CR/CRLF/F/LF/NL/V)
LVLS TO CONSOL ===> 49 WS HOME OPSYS ===> WS FILE EXT ===>
------------- COMPONENT LIST OPTIONS ----------------
FWD/REV DELTA ===> R (F/R) AUTO CONSOL ===> Y (Y/N) CONSOL AT LVL ===> 96
LVLS TO CONSOL ===> 25
--------------------- LIBRARIES ---------------------
BASE/IMAGE LIBRARY ===> CA.ENDEVOR.SMPL&C1ST..BASE
DELTA LIBRARY ===> CA.ENDEVOR.SMPL&C1ST..DELTA
INCLUDE LIBRARY ===>
SOURCE O/P LIBRARY ===>
EXPAND INCLUDES ===> N (Y/N)
 

A-4 Administration Guide

 A.1 Steps for Converting Forward to Reverse Delta

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.

Appendix A. Converting Delta Formats A-5

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-6 Administration Guide

 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 Target MOVE MOVE TRANSFER TRANSFER

Format Format with without with without
history history 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 A. Converting Delta Formats A-7

A-8 Administration Guide
Appendix B. Interfacing Endevor with CA Common
Services

Appendix B. Interfacing Endevor with CA Common Services B-1

B.1 Overview

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

B-2 Administration Guide

 B.2 Formatting Endevor Messages

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

Appendix B. Interfacing Endevor with CA Common Services B-3

B.3 How the Interface Works

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

B-4 Administration Guide

 B.4 Calling the Interface From a User Exit

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

Appendix B. Interfacing Endevor with CA Common Services B-5

B.5 Calling the Interface From a Processor

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

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

B-6 Administration Guide

 B.5 Calling the Interface From a Processor

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

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

Appendix B. Interfacing Endevor with CA Common Services B-7

B.5 Calling the Interface From a Processor

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

B-8 Administration Guide

 B.6 Setting Up the IP Addresses of Event Consoles

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

Appendix B. Interfacing Endevor with CA Common Services B-9

B.6 Setting Up the IP Addresses of Event Consoles

/(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,
// PARM='NODECK,OBJECT,NOTERM,LIST,XREF(SHORT)'
//SYSLIB DD DISP=SHR,DSN=iprfx.iqual.SOURCE
//SYSLIN DD DSN=&&SYSLIN,
// UNIT=tdisk,
// SPACE=(TRK,(3,5)),
// DISP=(NEW,PASS,DELETE),
// DCB=(RECFM=FB,LRECL=8,BLKSIZE=32)
//SYSPRINT DD SYSOUT=
//SYSPUNCH DD DUMMY
//SYSUT1 DD UNIT=tdisk,SPACE=(CYL,(1,1))
//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,
// DISP=(OLD,DELETE,DELETE)
//SYSLMOD DD DISP=SHR,DSN=uprfx.uqual.AUTHLIBHLIB(BC1TIPAD)
//SYSPRINT DD SYSOUT=
//SYSUT1 DD UNIT=tdisk,SPACE=(TRK,(5,15))

B-10 Administration Guide

Appendix C. Long Name and HFS File Support

Appendix C. Long Name and HFS File Support C-1

C.1 Long Name and HFS Support Overview

C.1 Long Name and HFS Support Overview

Long name support allows Endevor to support:
■ Case-sensitive element names for files added from 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

C.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 (.)

C.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:
■ Can not contain nulls or / (slash) characters
■ Does not support double- byte characters
■ Shells are case-sensitive, and distinguish between upper and lower case characters,
therefore FILE1 and file1 are not the same

C-2 Administration Guide

 C.1 Long Name and HFS Support Overview

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

C.1.3 Element Names

Element names can be 255 characters long, containing these characters:
■ Uppercase letters
■ Lowercase letters
■ Numbers
■ National characters
■ Period(.)
■ Hyphen (-)
■ Underscore(_)

Appendix C. Long Name and HFS File Support C-3

C.1 Long Name and HFS Support Overview

C.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 / HFS support

ISPF No support for actions involving long name elements or path names.
Element names greater than 10 characters are truncated in lists. The
Quick Edit
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:
■ Left bracket ({)
■ The first 39 characters of the path name
■ An ellipsis (...)
■ Right bracket (})
Batch (SCL) ■ Element names can be 255 characters long, containing
mixed-case
API ■ Periods, underscores, and hyphens are valid characters
■ Path names can be 768 characters, not including the HFS file
Enterprise name
Workbench

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

C-4 Administration Guide

 C.1 Long Name and HFS Support Overview

Appendix C. Long Name and HFS File Support C-5

C.2 Long Name Elements

C.2 Long Name Elements

C.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 HFS DSN

Characteristics
Long
1— alphanumeric, Yes No
mixed case and @, $, #, ., -, _
Short
2— alphanumeric, Yes No
mixed case and @, $, #, ., -, _
Short
2— alphanumeric, Yes Yes
upper case and @, $, #
Note:

1: Names are greater than 10 and less than 256 characters

2: Names are less than or equal to 10 characters

C-6 Administration Guide

 C.2 Long Name Elements

C.2.2 Storing Long Name Elements

The following table summarizes the supported storage definitions and any limitations
for elements in Endevor.

Element Name HFS DSN HFS DSN

Characteristics Base Base Source Source
Output Output
Long
1— alphanumeric, Yes Forward- Yes No
mixed case and @, $, #, ., -, _ delta
only
Short
2— alphanumeric, Yes Forward- Yes No
mixed case and @, $, #, ., -, _ delta
only
Short
2— alphanumeric, Yes Yes Yes Yes
upper case and @, $, #
Note:

1: Names are greater than 10 and less than 256 characters

2: Names are less than or equal to 10 characters

C.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 Sample Element ISPF/Quick Edit Enterprise

Characteristics Name Workbench
Long
1— alphanumeric, abcdefghijklm {abcde...}
3 abcdefghijklm
mixed case and @, $, #, ., -, _
Short
2— alphanumeric, LoNgNaMe {LoNgNaMe}
3 LoNgNaMe
mixed case and @, $, #, ., -, _
Short
2— alphanumeric, ELEMENT1 ELEMENT1 ELEMENT1
upper case and @, $, #
Note:

1: Names are greater than 10 and less than 256 characters

2: Names are less than or equal to 10 characters

3: Element information is not available from these lists, it is only accessible from the Enterprise Workbench.
If there are multiple long name elements and the first five characters are identical, ISPF displays a single entry.

Appendix C. Long Name and HFS File Support C-7

C.3 HFS Files and Directories

C.3 HFS Files and Directories

C.3.1 HFS Directories and Endevor Libraries

With USS/HFS File support some Endevor libraries can be located in HFS partitions.
Currently, the only supported libraries are:
■ Base
■ Source output
■ Include

Library OS/390 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

Note: Processors can write outputs to HFS directories.

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

C-8 Administration Guide

 C.3 HFS Files and Directories

C.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' Y
Retrieve 'to' Y
Archive 'to' N
Restore 'from' N
Transfer 'from archive' and N
'to archive'
Unload 'to' N
Reload 'from' N

C.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, Displays full name N/A {abcde...}
Element name
Master display, Displays full path N/A Brackets if > 44 characters
'Retrieved to'
Master display, Displays full path N/A Brackets if > 44 characters
'Added from'
Add\Update, Input allowed Input not allowed Full HFS path and file
'Add from' name
Retrieve, Input allowed Input not allowed Full HFS path and file
'Retrieve to' name
Type definition Input allowed Input not allowed Using site symbolics
Base libraries
Source output libraries
Include libraries
Type display Displays full path Displays symbolics N/A
Note: N/A - Not applicable

Appendix C. Long Name and HFS File Support C-9

C.4 HFS RECFM Field in Type Definition Panel

C.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 ----------------------- TYPE DEFINITION -------------------------------


COMMAND ===>

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

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

DESCRIPTION ===> Cobol Source Code

UPDATED: BY
----------------- ELEMENT OPTIONS -------------------
FWD/REV/IMG DELTA ===> R (F/R/I) COMPRESS BASE/ENCRYPT NAME ===> Y (Y/N)
DFLT PROC GRP ===> CLENBL REGRESSION PCT ===> 75 REGR SEV ===> W (I/W/C/E)
SOURCE LENGTH ===> 8 COMPARE FROM ===> 7 COMPARE TO ===> 72
AUTO CONSOL ===> Y (Y/N) LANGUAGE ===> cobol PV/LB LANG ===> DATA
CONSOL AT LVL ===> 96 HFS RECFM ===> NL (COMP/CR/CRLF/F/LF/NL/V)
LVLS TO CONSOL ===> 49 WS HOME OPSYS ===> WS FILE EXT ===>
------------- COMPONENT LIST OPTIONS ----------------
FWD/REV DELTA ===> R (F/R) AUTO CONSOL ===> Y (Y/N) CONSOL AT LVL ===> 96
LVLS TO CONSOL ===> 25
--------------------- LIBRARIES ---------------------
BASE/IMAGE LIBRARY ===> CA.ENDEVOR.SMPL&C1ST..BASE
DELTA LIBRARY ===> CA.ENDEVOR.SMPL&C1ST..DELTA
INCLUDE LIBRARY ===>
SOURCE O/P LIBRARY ===>
EXPAND INCLUDES ===> N (Y/N)
 

C.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 4000 bytes.

C-10 Administration Guide

Appendix D. Catalog Utilities

Appendix D. Catalog Utilities D-1

D.1 Overview

D.1 Overview
Endevor incorporates the use of an Element Catalog file to support long element
names and to boost performance by reducing the volume of I/O operations.

D-2 Administration Guide

 D.2 Building the Element Catalog

D.2 Building the Element Catalog

In moving to Endevor Release 4.0, you need to perform several post-installation steps
to prepare for implementing the new release. These steps are summarized in the
following table and described in detail in the following sections.

Step What You Do JCLLIB

Member/JOB
1 Copy all your MCF VSAM data set to new BC1JXMCF
data sets with Release 4.0 VSAM attributes.
2 Copy your Package VSAM data set to a new BC1JXPCF
data set with Release 4.0 VSAM attributes.
3 Define Endevor's release 4.0 catalog VSAM BC1JDCAT
data set.
4 Add the ELMCATL= catalog parameter to BC1JDEFT
the C1DEFLTS table.
5 Run Endevor's Catalog Build utility against BC1JXCAT
all defined Environments.

D.2.1 Step 1: Converting Your Existing MCF VSAM Data Sets

The MCF data set's maximum record length has changed for this release. 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.

D.2.1.1 BC1JXMCF JCL

// ( COPY JOBCARD )
//
// 
// BC1JXMCF - THIS JOB WILL CONVERT THE ENDEVOR VSAM 
// MASTER CONTROL FILES (MCF) FROM RELEASE 3.5 & UP 
// TO RELEASE 4. ATTRIBUTES. THIS IS A ONE TIME 
// CONVERSION THAT WILL NEED TO BE RUN FOR EACH 
// SET OF EXISTING ENVIRONMENT MCFS. 
// 
// THE FOLLOWING CHANGES MUST BE MADE BEFORE THIS JOB CAN 
// BE RUN: 
// 
// 1. REVIEW THE NAMES OF THE VSAM MCF FILES YOU WILL BE 
// CONVERTING. THIS JCL IS SETUP WITH THE DEFAULT 
// INSTALLATION NAMES: 

Appendix D. Catalog Utilities D-3

D.2 Building the Element Catalog

// STAGE 1- uprfx.uqual.STAGE1 

// STAGE 2- uprfx.uqual.STAGE2 
// 2. DETERMINE THE CURRENT VOLSER AND SPACE ALLOCATIONS 
// FOR EACH MCF (STAGE 1 & 2). 
// 3. USE THIS INFORMATION TO UPDATE THE CYLINDERS(NN NN) 
// IN JOB STEPS 2, 3 AND 4 AND THE VOLSER (VVOLSER) IN 
// JOB STEPS 2 AND 3. 
// 
//  DO NOT USE THIS JOB FOR FUTURE VSAM REPRO CLEAN-UP.  
//  JOB BC1JRMCF (IN THIS LIBRARY) IS SET-UP FOR THIS  
//  PURPOSE.  
// 
//
//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=
//SYSIN DD 
DELETE 'uprfx.uqual.V1SEQ' PURGE
DELETE 'uprfx.uqual.V2SEQ' PURGE
//
//STEP2 EXEC PGM=IDCAMS
//TEMPSEQ1 DD DSN=uprfx.uqual.V1SEQ,DISP=(NEW,CATLG,DELETE),
// UNIT=PDISK,VOL=SER=DVOLSER,SPACE=(CYL,(NN,NN),RLSE),
// DCB=(RECFM=VB,LRECL=121,BLKSIZE=)
//TEMPSEQ2 DD DSN=uprfx.uqual.V2SEQ,DISP=(NEW,CATLG,DELETE),
// UNIT=PDISK,VOL=SER=DVOLSER,SPACE=(CYL,(NN,NN),RLSE),
// DCB=(RECFM=VB,LRECL=121,BLKSIZE=)
//CURSTG1 DD DSN=uprfx.uqual.STAGE1,DISP=OLD,
// AMP='BUFNI=1,BUFND=1'
//CURSTG2 DD DSN=uprfx.uqual.STAGE2,DISP=OLD,
// AMP='BUFNI=1,BUFND=1'
//SYSPRINT DD SYSOUT=
//SYSIN DD 
REPRO IFILE(CURSTG1) OFILE(TEMPSEQ1)
REPRO IFILE(CURSTG2) OFILE(TEMPSEQ2)
//
//STEP3 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=
//SYSIN DD 
DELETE 'uprfx.uqual.STAGE1' PURGE
DEFINE CLUSTER (NAME('uprfx.uqual.STAGE1') -
SPEED -
UNIQUE -
FREESPACE(3 3) -
CYLINDERS(NN NN) -
VOLUMES(VVOLSER) -
RECORDSIZE(64 12) KEYS(28 ) SHR(3 3)) -
DATA (NAME('uprfx.uqual.STAGE1.DATA') CISZ(8192)) -
INDEX (NAME('uprfx.uqual.STAGE1.INDEX') CISZ(248))
//
// 
// STEP4 - ALLOCATE THE STAGE 2 VSAM FILE 
//  
//

D-4 Administration Guide

 D.2 Building the Element Catalog

//
//STEP4 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=
//SYSIN DD 
DELETE 'uprfx.uqual.STAGE2' PURGE
DEFINE CLUSTER (NAME('uprfx.uqual.STAGE2') -
SPEED -
UNIQUE -
FREESPACE(3 3) -
CYLINDERS(NN NN) -
VOLUMES(VVOLSER) -
RECORDSIZE(64 12) KEYS(28 ) SHR(3 3)) -
DATA (NAME('uprfx.uqual.STAGE2.DATA') CISZ(8192)) -
INDEX (NAME('uprfx.uqual.STAGE2.INDEX') CISZ(248))
//
//STEP5 EXEC PGM=IDCAMS
//CURSEQ1 DD DSN=uprfx.uqual.V1SEQ,DISP=OLD
//CURSEQ2 DD DSN=uprfx.uqual.V2SEQ,DISP=OLD
//NEWSTG1 DD DSN=uprfx.uqual.STAGE1,DISP=OLD,
// AMP='BUFNI=1,BUFND=1'
//NEWSTG2 DD DSN=uprfx.uqual.STAGE2,DISP=OLD,
// AMP='BUFNI=1,BUFND=1'
//SYSPRINT DD SYSOUT=
//SYSIN DD 
REPRO IFILE(CURSEQ1) OFILE(NEWSTG1)
REPRO IFILE(CURSEQ2) OFILE(NEWSTG2)
//

D.2.2 Step 2: Converting Your Existing Package VSAM Data Sets

The Package data set's maximum record length has also changed for this release. 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.

D.2.2.1 BC1JXPCF JCL

// ( COPY JOBCARD )
//
// 
// (C) 22 COMPUTER ASSOCIATES INTERNATIONAL, INC. 
// 
// BC1JXPCF - THIS JOB WILL CONVERT THE ENDEVOR VSAM PACKAGE 
// FILE FROM PRE-R4. ATTRIBUTES TO R4. ATTRIBUTES. 
// (THIS IS A ONE-TIME CONVERSION.) 
// 
//  DO NOT USE THIS JOB FOR FUTURE VSAM REPRO CLEAN-UP.  
//  JOB BC1JRPKG (IN THIS LIBRARY) IS SET UP FOR THIS  
//  PURPOSE.  
// 
// 

Appendix D. Catalog Utilities D-5

D.2 Building the Element Catalog

// STEP1 WILL DELETE THE SEQUENTIAL FILE IN CASE AN OLD 

// COPY EXISTS. 
// STEP2 WILL REPRO THE EXISTING VSAM PACKAGE DATASET 
// TO THE SEQUENTIAL FILES. 
// STEP3A WILL DELETE AND REDEFINE THE VSAM PACKAGE DATASET. 
// STEP3B WILL DELETE AND REDEFINE THE VSAM PACKAGE DATASET. 
// FOR L-SERV USERS ONLY. 
// STEP4 WILL REPRO THE SEQUENTIAL FILE INTO THE NEW VSAM 
// PACKAGE DATASET. 
// 
//  NOTE TO NON L-SERV USERS  
// 
// IF ARE NOT USING L-SERV TO MANAGE THE ENDEVOR PACKAGE DATASET 
// AT THIS TIME, PLEASE INSURE THE FOLLOWING ADJUSTMENTS TO 
// THIS JCL ARE MADE: 
// 
// - DELETE STEP 3B. 
// - ADJUST THE CONDION CODES IN STEP 4 TO ONLY CHECK FOR STEP 
// 3A. 
// - EXECUTE STEP 3A TO ALLOCATE THE VSAM CLUSER WITH THE 
// PROPER ATTRIBUTES FOR NON L-SERV USERS. 
// 
//  NOTE TO L-SERV USERS  
// 
// IF YOU PLAN TO USE L-SERV TO MANAGE THE ENDEVOR PACKAGE 
// DATASET, PLEASE INSURE THE FOLLOWING ADJUSTMENTS 
// TO THIS JCL ARE MADE: 
// 
// - PLEASE INSURE L-SERV IS PROPERLY INSTALLED 
// - DELETE STEP 3A. 
// - ADJUST THE CONDION CODES IN STEP 4 TO ONLY CHECK FOR STEP 
// 3B. 
// - EXECUTE STEP 3B TO ALLOCATE THE VSAM CLUSER WITH THE 
// PROPER ATTRIBUTES FOR L-SERV USERS ENABLING THE COMPRESS 
// UTILITY TO BE USED. 
// 
// NO OTHER ATTRIBUTES OF THESE FILES MAY BE ALTERED WITHOUT 
// FIRST CONSULTING ENDEVOR TECHNICAL SUPPORT. 
// 
//
//
// 
// STEP1 - DELETE THE SEQUENTIAL FILE IN CASE AN OLD 
// COPY EXISTS. 
// 
//
//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=
//SYSIN DD 
DELETE 'uprfx.uqual.V1PKG' PURGE
//
// 
// STEP2 - REPRO THE EXISTING VSAM PACKAGE DATASET 

D-6 Administration Guide

 D.2 Building the Element Catalog

// TO THE SEQUENTIAL FILES. 

// 
//
//STEP2 EXEC PGM=IDCAMS
//TEMPPKG DD DSN=uprfx.uqual.V1PKG,DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,VOL=SER=DVOLSER,SPACE=(CYL,(1,5),RLSE),
// DCB=(RECFM=VB,LRECL=121,BLKSIZE=)
//CURPKG DD DSN=uprfx.uqual.PACKAGE,DISP=OLD,
// AMP='BUFNI=1,BUFND=1'
//SYSPRINT DD SYSOUT=
//SYSIN DD 
REPRO IFILE(CURPKG) OFILE(TEMPPKG)
//
// 
// STEP3A - DELETE AND REDEFINE THE VSAM PACKAGE DATASET. 
// 
//
//STEP3A EXEC PGM=IDCAMS,COND=(,LT,STEP2)
//SYSPRINT DD SYSOUT=
//SYSIN DD 
DELETE 'uprfx.uqual.PACKAGE' PURGE
DEFINE CLUSTER (NAME('uprfx.uqual.PACKAGE') -
SPEED -
UNIQUE -
FREESPACE(3 3) -
CYLINDERS(NN NN) -
VOLUMES(VVOLSER) -
RECORDSIZE(64 37) KEYS(64 8) SHR(3 3)) -
DATA (NAME('uprfx.uqual.PACKAGE.DATA') CISZ(8192)) -
INDEX (NAME('uprfx.uqual.PACKAGE.INDEX') CISZ(248))
//
// 
//  FOR L-SERV USERS ONLY  
// 
// STEP3B - DELETE AND REDEFINE THE VSAM PACKAGE DATASET. 
// 
//
//STEP3B EXEC PGM=IDCAMS,COND=(,LT,STEP2)
//SYSPRINT DD SYSOUT=
//SYSIN DD 
DELETE 'uprfx.uqual.PACKAGE' PURGE
DEFINE CLUSTER (NAME('uprfx.uqual.PACKAGE') -
NOIMBED -
SPEED -
SUBALLOCATION -
REUSE -
FREESPACE(3 3) -
CYLINDERS(NN NN) -
VOLUMES(VVOLSER) -
RECORDSIZE(64 37) KEYS(64 8) SHR(1 3)) -
DATA (NAME('uprfx.uqual.PACKAGE.DATA') CISZ(8192)) -
INDEX (NAME('uprfx.uqual.PACKAGE.INDEX') CISZ(248))
//

Appendix D. Catalog Utilities D-7

D.2 Building the Element Catalog

// 
// STEP4 - REPRO THE SEQUENTIAL FILE INTO THE NEW VSAM 
// PACKAGE DATASET. 
// 
//
//STEP4 EXEC PGM=IDCAMS,COND=((,LT,STEP3A),(,LT,STEP3B))
//CURPKG DD DSN=uprfx.uqual.V1PKG,DISP=OLD
//NEWPKG DD DSN=uprfx.uqual.PACKAGE,DISP=OLD,
// AMP='BUFNI=1,BUFND=1'
//SYSPRINT DD SYSOUT=
//SYSIN DD 
REPRO IFILE(CURPKG) OFILE(NEWPKG)
//

D.2.3 Step 3: Defining the MCF Catalog Data Set

Endevor Release 4.0 uses a catalog data set 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 you must not use a prior release to access 4.0
data. If you do, the catalog becomes out of sync with the MCFs.

D.2.3.1 BC1JJB07 JCL

// (COPY JOBCARD)
//
// 
// (C) 22 COMPUTER ASSOCIATES INTERNATIONAL, INC. 
// 
//  THIS IS THE ENDEVOR 4. ELEMENT CATALOG MODEL  
// 
// BC1JJB7 - DEFINE VSAM ELEMENT CATALOG & ELEMENT 
// CROSS-REFERENCE FILES FOR ENDEVOR 4. 
// 
// THE USER SHOULD ADJUST THE VOLUME, NODE AND CATALOG 
// INFORMATION TO CONFORM TO THE LOCAL SHOP STANDARDS. 
// 
// THE SPACE ALLOCATION OF THE VSAM FILE SHOULD BE 
// REVIEWED BASED ON THE PLANNED USAGE AND NUMBER OF 
// ELEMENTS TO BE MANAGED. 
// 
// NOTES: 
// 1. IF RLS (RECORD-LEVEL-SHARING) WILL BE USED TO MANAGE 
// THE ELEMENT CATALOG AND CROSS-REFERENCE FILES: 
// A. INSERT A LOG(NONE) PARAMETER IN THE DEFINE CLUSTER 
// CONTROL STATEMENTS. 
// B. CHANGE THE SHR(3,3) PARAMETERS TO SHR(1,3). 
// 
//-------------------------------------------------------------------

D-8 Administration Guide

 D.2 Building the Element Catalog

// DELETE AND REALLOCATE AN ENDEVOR ELEMENT CATALOG DATA SET 

//-------------------------------------------------------------------
//ALLOCCAT EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=
//SYSIN DD 
DELETE uprfx.uqual.ELMCATL
DEFINE CLUSTER (NAME(uprfx.uqual.ELMCATL) -
SPEED -
UNIQUE -
FREESPACE(3 3) -
CYLINDERS(NN NN) -
VOLUMES(VVOLSER) -
RECORDSIZE(64 117) KEY(255 ) SHR(3 3)) -
DATA (NAME('uprfx.uqual.ELMCATL.DATA') CISZ(8192)) -
INDEX (NAME('uprfx.uqual.ELMCATL.INDEX') CISZ(248))
DELETE uprfx.uqual.ELMCATL.EINDEX
DEFINE CLUSTER (NAME(uprfx.uqual.ELMCATL.EINDEX) -
SPEED -
UNIQUE -
FREESPACE(3 3) -
CYLINDERS(NN NN) -
VOLUMES(VVOLSER) -
RECORDSIZE(287 4) KEY(1 ) SHR(3 3)) -
DATA (NAME('uprfx.uqual.ELMCATL.EINDEX.DATA') CISZ(8192)) -
INDEX (NAME('uprfx.uqual.ELMCATL.EINDEX.INDEX') CISZ(248))
//

D.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, X
ELMCATL='CA.PROD.ELMCATL', X

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

BC1PXCAT 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 4.0, you must have run
the conversion utility against all environments defined in your C1DEFLTS table. Use
member BC1JXCAT from your Endevor JCL library to tailor the job stream to do
your initial build of the element catalog.

Appendix D. Catalog Utilities D-9

D.2 Building the Element Catalog

D.2.5.1 BC1JXCAT JCL

//(JOBCARD)
//
// 
// (C) 22 COMPUTER ASSOCIATES INTERNATIONAL, INC. 
// 
// PURPOSE: EXTRACTS ALL MCF ELEMENTS FROM ENDEVOR AT THE 3.9 
// LEVEL OR EARLIER, AND BUILDS CATALOGUE ENTRIES FOR THE NEW VSAM 
// CONTROL DATA SET FOR ENDEVOR 4.. 
// 
// CONTROL STATEMENT SPECIFIED IN THE BSTIPT DD STATEMENT CONTROL 
// THE ENVIRONMENTS FOR WHICH MCF INFORMATION IS EXTRACTED. 
// 
// ONLY ONE REQUIRED STATEMENT: 
// ENVIRONMENT ENVIRONMENT_NAME . SPECIFIES THE ENVIRONMENT 
// FOR WHICH MCF INFORMATION IS 
// TO BE EXTRACTED. MULTIPLE 
// ENVIRONMENT MAY BE LISTED. 
// 
// EXAMPLES: 
// FOR SINGLE ENVIRONMENT STATEMENT SPECIFICATION: 
// ENVIRONMENT ENV1. 
// 
// FOR MULTIPLE ENVIRONMENT STATEMENT SPECIFICATION: 
// ENVIRONMENT (ENV1,ENV2,ENV3). 
// 
// FOR MULTIPLE ENVIRONMENTS SPECIFIED ON MULTIPLE STATEMENTS: 
// ENVIRONMENT (ENV1,ENV2,ENV3). 
// ENVIRONMENT (ENV4,ENV5,ENV6). 
// 
//
//LNDVR EXEC PGM=NDVRC1,PARM='BC1PXCAT',REGION=496K,DYNAMNBR=15
//STEPLIB DD DISP=SHR,DSN=uprfx.uqual.AUTHLIB
// DD DISP=SHR,DSN=iprfx.iqual.AUTHLIB
//CONLIB DD DISP=SHR,DSN=iprfx.iqual.CONLIB
//BSTLST DD SYSOUT=
//BSTERR DD SYSOUT=
//NOJRNL DD DUMMY
//BSTIPT DD 
// INSERT CONTROL STATEMENT HERE
//

D-10 Administration Guide

 D.3 Endevor Considerations

D.3 Endevor Considerations

As of 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 R4.0
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 R4.0 is downwardly compatible with Endevor R3.9, provided no Endevor
R4.0-only features were implemented (long element names, etc.)
■ Endevor control tables (C1DEFLTS, ENDICNFG, ENCOPTBL, etc.) are validated
at Endevor start-up time to ensure all tables are R4.0-compatible.
■ The Endevor R4.0 Element Registration feature can be activated in WARN,
CAUTION or ERROR mode (and switched from one mode to the other at any
time).

Appendix D. Catalog Utilities D-11

D.4 Catalog Rename Utility

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

D.4.1 BC1JXCNM JCL

To invoke Validate or Update mode, change the PARM= parameter on the execute
statement.
PARM='BC1PXCNMVALIDATE' indicates validate mode.
PARM='BC1PXCNMUPDATE' indicates update mode.
PARM='BC1PXCNM' defaults to validate mode.
// (COPY JOBCARD)
//
// (C) 22 COMPUTER ADSSOCIATES INTERNATIONAL, INC.
//
// BC1JXCNM - RENAME THE MCF'S CATALOG NAME TO THE NAME SPECIFIED
// IN THE C1DEFLTS TABLE.
//
// THE FOLLOWING CHANGES MUST BE MADE BEFORE THIS JOB CAN BE RUN:
//

D-12 Administration Guide

 D.4 Catalog Rename Utility

// 1. ADJUST THE PARM STATEMENT ON THE EXECUTE STATEMENT TO

// EITHER VALIDATE OR UPDATE.
// PARM='BC1PXCNMUPDATE' -OR-
// PARM='BC1PXCNMVALIDATE'
//
// NOTE: STEP IS CURRENTLY SET TO VALIDATE.
//
// BC1PXCNM RUNS IN TWO MODES: VALIDATE AND UPDATE.
//
// IN VALIDATE MODE, THE PROGRAM WILL EXAMINE ALL MCF'S DEFINED IN
// C1DEFLTS TABLE AND WILL REPORT BACK WHICH MCF'S AGREE OR DISAGREE
// WITH THE C1DEFLTS CATALOG NAME.
//
// IN UPDATE MODE, THE PROGRAM WILL EXAMINE ALL MCF'S DEFINED IN THE
// C1DEFLTS TABLE AND WILL ALSO REPORT BACK WHICH MCF'S AGREE AND
// DISAGREE WITH THE C1DEFLTS CATALOG NAME, BUT FOR EACH DISAGREEMENT,
// THOSE MCF'S WILL BE UPDATED TO REFLECT THE C1DEFLTS CATALOG NAME.
//
//--------------------------------------------------------------------
// STEP1 - BC1PXCNM: RENAME OR VALIDATE MCF'S CATALOG NAME.
//--------------------------------------------------------------------
//STEP1 EXEC PGM=NDVRC1,PARM='BC1PXCNMVALIDATE',
// REGION=496K,COND=(,LE)
//STEPLIB DD DISP=SHR,DSN=uprfx.uqual.AUTHLIB
// DD DISP=SHR,DSN=iprfx.iqual.AUTHLIB
//CONLIB DD DISP=SHR,DSN=iprfx.iqual.CONLIB
//BSTLST DD SYSOUT=
//SYSUDUMP DD SYSOUT=
//BSTERR DD SYSOUT=
//NOJRNL DD DUMMY
//

Appendix D. Catalog Utilities D-13

D.4 Catalog Rename Utility

D.4.2 Sample Report

(C) 22 Computer Associates International, Inc Endevor xx/xx/xx xx:xx:xx PAGE 1
RELEASE x.x SERIAL XXXXXX

ENDEVOR Stage Catalog Name Update/Validation UTILITY LOG

Endevor Catalog Name: CA.ENDEVOR.ELMCATL

Run Mode: VALIDATE

ENVIRONMENT ENV1 STAGE 1 CATALOG NAME CA.ENDEVOR.ELMCATL.............................. AGREES WITH C1DEFLTS TABLE.
ENVIRONMENT ENV1 STAGE 2 CATALOG NAME CA.ENDEVOR.ELMCATL.............................. AGREES WITH C1DEFLTS TABLE.
ENVIRONMENT ENVA STAGE 1 CATALOG NAME CA.ENDEVOR.ELMCATL.............................. AGREES WITH C1DEFLTS TABLE.
ENVIRONMENT ENVA STAGE 2 CATALOG NAME CA.ENDEVOR.ELMCATL.............................. AGREES WITH C1DEFLTS TABLE.

CNM12I ALL STAGES AGREE WITH THE C1DEFLTS CATALOG NAME, NO UPDATE IS NECESSARY

CNM14I TOTAL NUMBER OF ENVIRONMENTS PROCESSED: 2

CNM17I NUMBER OF STAGES THAT DO NOT MATCH THE NEW C1DEFLTS CATALOG NAME: 
CNM16I NUMBER OF STAGES THAT MATCH THE NEW C1DEFLTS CATALOG NAME: 4

(C) 22 Computer Associates International, Inc Endevor xx/xx/xx xx:xx:xx PAGE 1
RELEASE x.x SERIAL XXXXXX

ENDEVOR Stage Catalog Name Update/Validation UTILITY LOG

Endevor Catalog Name: CA.ENDEVOR.ELMCATL

Run Mode: UPDATE

ENVIRONMENT ENV1 STAGE 1 CATALOG NAME CA.ENDEVOR.ELMCATL.............................. AGREES WITH C1DEFLTS TABLE.
ENVIRONMENT ENV1 STAGE 2 CATALOG NAME CA.ENDEVOR.ELMCATL.............................. AGREES WITH C1DEFLTS TABLE.
ENVIRONMENT ENVA STAGE 1 CATALOG NAME CA.ENDEVOR.ELMCATL.............................. AGREES WITH C1DEFLTS TABLE.
ENVIRONMENT ENVA STAGE 2 CATALOG NAME CA.ENDEVOR.ELMCATL.............................. AGREES WITH C1DEFLTS TABLE.

CNM1I NO STAGE RECORDS UPDATES WERE NECESSARY, ALL SET WITH THE CURRENT CATALOG NAME

CNM14I TOTAL NUMBER OF ENVIRONMENTS PROCESSED: 2

CNM15I NUMBER OF STAGES UPDATED TO NEW C1DEFLTS CATALOG NAME: 
CNM16I NUMBER OF STAGES THAT MATCH THE NEW C1DEFLTS CATALOG NAME: 4

(C) 22 Computer Associates International, Inc Endevor xx/xx/xx xx:xx:xx PAGE 1
RELEASE x.x SERIAL XXXXXX

ENDEVOR Stage Catalog Name Update/Validation UTILITY LOG

Endevor Catalog Name: CA.PROD.ELMCATL

Run Mode: UPDATE

ENVIRONMENT ENV1 STAGE 1 CATALOG NAME CA.ENDEVOR.ELMCATL.............................. DIFFERS FROM C1DEFLTS TABLE.
ENVIRONMENT ENV1 STAGE 2 CATALOG NAME CA.ENDEVOR.ELMCATL.............................. DIFFERS FROM C1DEFLTS TABLE.
ENVIRONMENT ENVA STAGE 1 CATALOG NAME CA.ENDEVOR.ELMCATL.............................. DIFFERS FROM C1DEFLTS TABLE.
ENVIRONMENT ENVA STAGE 2 CATALOG NAME CA.ENDEVOR.ELMCATL.............................. DIFFERS FROM C1DEFLTS TABLE.

CNM11I STAGE UPDATES WERE NECESSARY, NOT ALL AGREED WITH CATALOG NAME ENTRY IN C1DEFLTS

CNM14I TOTAL NUMBER OF ENVIRONMENTS PROCESSED: 2

CNM15I NUMBER OF STAGES UPDATED TO NEW C1DEFLTS CATALOG NAME: 4
CNM16I NUMBER OF STAGES THAT MATCH THE NEW C1DEFLTS CATALOG NAME: 

D-14 Administration Guide

Index

Special Characters B
$CIPOREC 6-14 Base libraries
$SMFBKDS 7-13 about 1-16
$SMFHDDS 7-6 allocating A-3
$SMFREC1 7-8 resizing A-3
$SMFREC2 7-12 symbolics 2-40
Base members 9-7
BC1JJB07 D-8
A BC1JRELD A-5
Action BC1JUNLD A-4
availability 1-19 BC1JVALD A-5
blocks 7-3 BC1JXCAT D-10
by job function 1-20 BC1MPMCF D-5
Display 1-19 BC1MXMCF D-3
Prompt panel 6-5 BC1PNCPY 9-8
Action Records BC1PTRAP REXX procedure B-6
blocks 7-5, 7-12, 7-13 BC1PTRPO B-5
SMF 7-3 Blocks
Add Action about 7-3
CCIDs updates 6-6 action-specific 7-13
function 1-19 Buffer pool 9-10
specifying for elements 6-7
Adding options to User Options Menu 8-4
Addresses IP B-9 C
Adjusting type definitions A-4 C1DEFLT macros 3-3
AllFusion CA-Librarian 9-8 C1DEFLTs
AllFusion CA-Panvalet 9-8 adding the element catalog D-9
Allocating base libraries A-3 CA Common Services Event Manager (CCS) B-3
Analyzing types for deltas A-2 Calling the Endevor interface B-5
Archive Action 1-19 Capturing elements A-4
Attributes CCIDs
BC1JJB07 D-8 about 6-2
BC1MXpCF D-5 Add Action updates 6-6
LOG 9-11 data set sample definition 6-16
tuning 9-14 definition data set 6-14, 6-15
Audit stamps 1-22 Delete Action updates 6-10
Endevor's impact on actions 6-11
fields 6-3
Generate Action updates 6-8

Index X-1
CCIDs (continued) Data blocks
ISPF Text Editor 6-15 about 7-3
Move Action updates 6-9 security 7-8
predefining 6-13 Data sets
requiring 6-4 CCIDs definition 6-14
Restore Action updates 6-11 definitions for type 2-46
Retrieve Action updates 6-8 field definition 6-16
sample definition 6-16 package 1-16
Transfer Action updates 6-9 sample definition 6-16
updating fields 6-6 Type panel 2-47
validation 6-13 Type Request panel 2-46
Change Control Identifiers see CCIDs Defaults Table
Changing name of data set for a system 2-46 about 1-3
Classifications for Inventory maps 3-4 establishing routes 3-3
Classifying elements 1-13 Defining
Cloning 2-23 environments 1-9
Commands 1-19 maps 3-3
Comments see CCIDs new systems 2-16
Communication Server 9-10 processing sequence 2-42
Components of logical structure 1-7 subsystems 1-11, 2-26
Consolidation trigger level 9-5 symbolics 2-40
Conventions for naming types 2-38 systems 1-10, 2-16
Converging types 1-12, 2-29, 2-42
routes 3-6 Definition file 6-14
systems in a route 3-7 Delete
Conversion processors 1-21
attributes D-5 Delete Action
BC1MXMCF D-3 CCIDs updates 6-10
catalog build D-9 function 1-19
MCF D-3 Deltas
MCF catalog D-3 analyzing types A-2
package data sets D-5 consolidation trigger level 9-5
Conversions conversions A-2, A-7
deltas A-2, A-6 element consolidation 9-5
forward/reverse to full-image A-7 formats 9-3
CONWRITE utility forward 2-39
about 9-3 full-image 2-40
modifying processors A-3 libraries 1-16
tuning processors 9-13 library types 9-7
Copy Action 1-19 number of levels to retain 9-5
Copyback 6-8 resizing libraries A-3
Copying system, subsystems and types 2-23 reverse 2-39
Creating storage formats 2-39
CCID definition data set 6-14 symbolics 2-40
executable forms of elements 1-21 Display
Cycle, software life 1-4 environment information 2-49
Site Information panel 2-6
Stage Information panel 2-14
D DSECTs
Data $SMFBKDS 7-13
sets $SMFHDDS 7-6
security 1-23

X-2 Administration Guide

DSECTs (continued) Environment (continued)
$SMFREC1 7-8 displaying information 2-49
$SMFREC2 7-12 Information panel 2-49
about 7-6 mapping 9-6
SMF security records 7-3 options menu 2-3
Duplicate element names ESI 1-23
processor group 5-4 Establishing routes in the Defaults Table 3-3
subsystem level 5-3 Evaluating processors A-3
system level 5-3 Event Manager for B-3
duplicate elements 5-2 Event Manager for CA Common Services (CCS) B-3
Duplicating system, subsystems and types 2-23 Execute
BC1JRELD A-5
BC1JVALD A-5
E forms of elements 1-21
Editor 6-15 Exit program for Endevor users B-5
Element Catalog 1-16 External Security Interface (Endevor ESI) 1-23
build D-9
building D-3
C1DEFLTs D-9 F
MCF conversion D-3 Facility native security 1-23
Element Registration 5-2—5-6 Fields
Overview 5-2 $SMFHDDS DSECT 7-7
Elements $SMFREC1 DSECT 7-10
capturing A-4 $SMFREC2 DSECT 7-13
classifying 1-13 action block 7-17—7-21
creating executable forms 1-21 CCIDs 6-3
definition of 1-8 definition data set 6-16
delta consolidation 9-5 Endevor actions impact on 6-11
querying for 1-15 Environment Information panel 2-49
specifying an Add Action 6-7 Site Information panel 2-7
storage formats 2-39 Stage Information panel 2-14
unload A-4 Subsystem Definition 2-27
working with 1-19 System Definition panel 2-18
Endevor System Definition panel for cloning 2-24
Actions 1-19 Type Definition panel 2-32
calling the Interface B-5 Type Processing Sequence panel 2-44
definition data set 6-14 updating CCIDs 6-6
ESI 1-23 File definition 6-14
impact on fields 6-11 File processing for VSAM 9-9
inventory structure Footprints 1-22
classifying elements 1-13 Formats for deltas 9-3
setting up 1-8 Formatting messages B-3
LIB 9-7 Forward deltas
library list 1-16 about 2-39, 9-3
messages B-4 conversion to full-image A-7
security 1-23, 7-2 conversion to reverse A-2
updating CCIDs fields 6-6 Full-image deltas
ENFSAMP B-6 about 2-40, 9-4
Environment conversion from forward/reverse A-7
defining 1-9 Functions
definition of 1-7 for jobs 1-20

Index X-3
Functions (continued)
for menus 8-2 L
L-Serv 9-9
Levels number of to retain 9-5
G LIB 9-7
Generate Libraries
processors 1-21 about 1-16
Generate Action Base
CCIDs updates 6-8 allocating A-3
function 1-19 resizing A-3
symbolics 2-40
Deltas
H resizing A-3
Header blocks types 9-7
about 7-3 include 1-17
SMF 7-6 list 1-16
History types 9-7
Move Action 6-9 Life cycle of software 1-4
Transfer Action 6-9 List Action 1-19
WITH option for deltas A-7 Listing libraries 1-17
LOG attributes 9-11
Logical structure
I classifying elements 1-13
Identifying systems 2-4
components 1-7
Impact of Endevor on fields 6-11
querying 1-15
Implementing Record Level Sharing 9-12
setting up 1-8
Include libraries 1-17
Inventory map classifications 3-4
Inventory structure M
classifying elements 1-13 Macros
components 1-7 $CIPOREC 6-14
querying 1-15 for BC1TIPAD B-9
setting up 1-8 Managing actions 1-21
IP addresses B-9 Mapping multiple environments 9-6
IPVAL B-9 Maps 3-2—3-5
ISPF Master Control File (MCF)
panels 8-4 definition of 1-16
Text Editor 6-15 L-Serv 9-9
MCF Catalog
BC1MXMCF D-3
J convert D-3
JCL
defining D-8
attributes D-5, D-8
rename utility D-12
BC1JJB07 D-8
update D-12
BC1JXCAT D-10
utility D-12
BC1JXCNM D-12
validate D-12
BC1MXPCF D-5
Menus
element catalog build D-10
environment options 2-3
rename utility D-12
functions 8-2
modifying User Options 8-4
User Option 8-2

X-4 Administration Guide

Messages formatting B-3 Panels (continued)
Modifying System (continued)
processors A-3 Request 2-16
User Options Menu 8-4 Type
Monitoring L-Serv's performance 9-9 Data Set Request 2-46
Move Data Sets 2-47
processors 1-21 Definition 2-31
Move Action Processing Sequence 2-43
CCIDs updates 6-9 Request 2-29
function 1-19 Sequence Request 2-42
with history 6-9 User Options Menu 8-3
without history 6-9 using to define a map 3-4
Multiple mapping environments 9-6 Parameters
consolidation trigger level 9-5
for BC1PTRAP B-6
N for BC1PTRPO B-5
Naming conventions 2-38 IPVAL B-9
Native security facility 1-23 number of levels to consolidate 9-5
New systems defining 2-16 RECBUFFSIZE 9-9
Number of levels to retain 9-5 Partitioned data set (PDS) 1-8
PDS 1-8, 9-7
PDS/E 9-7
O Point in Time Recovery 9-9
Options
Predefining CCIDs 6-13
environment menu 2-3
Print Action 1-20
User Menu 8-2
Procedure
Output
adding options to User Options Menu 8-4
libraries 1-17
BC1PTRAP REXX B-6
management 1-21
changing name of data set for a system 2-46
Output Type
cloning inventory definitions 2-23
element registration 5-5
converting forward to reverse delta A-2
creating CCID definition data set 6-14
P defining
Package data set 1-16 new system 2-16
Package data sets subsystem 2-26
conversion D-5 type processing sequence 2-42
Packages 1-22 types 2-30
Panels removing options from User Options Menu 8-4
about 2-2 requiring CCIDs for a system 6-4
Action Prompt 6-5 Processing
Environment Information 2-49 backout 9-3
ISPF 8-4 sequence 2-42
Request 2-4 Processor Group
Selection List 2-4 duplicate elements 5-4
Site Information 2-6 element registration 5-4, 5-5
Stage Information 2-14 output type 5-5
Subsystem Processors
Definition 2-26 calling Endevor Interface B-6
Request 2-26 evaluating A-3
System libraries 1-16
Definition 2-17, 2-24 modifying A-3

Index X-5
Processors (continued) Security (continued)
tuning 9-13 record data block 7-8
types of 1-21 SMF 7-2
Programs Selection List panel 2-4
BC1PTRAP B-6 Sequence processing 2-42
BC1PTRPO B-5 Sequential data set 6-14
user exit B-5 Set
Providing stage id 3-3 package data 1-16
Setting up
inventory structure 1-8
Q IP addresses B-9
Querying the inventory structure 1-15 Signin Action 1-20
Site Information panel
display 2-6
R fields 2-7—2-13
RECBUFFSIZE 9-9
SMF
Record level sharing (RLS) 9-11
about 7-2
Records
Action Records 7-3
data block security 7-8
header block 7-6
SMF 7-3
security records 7-3
Recovery Point in Time 9-9
Software life cycle 1-4
Reload utility A-5
Source
Removing options from User Options Menu 8-4
management 1-21
Reporting 1-21
output libraries 1-17
Request panel 2-4
Specifying an Add Action for elements 6-7
Requiring CCIDs for a system 6-4
Stage
Resizing base libraries A-3
component 1-7
Restore Action
ID 3-3
CCIDs updates 6-11
Information panel 2-14
function 1-20
Stamps, audit 1-22
Retain number of levels to 9-5
Stand-alone routes 3-5
Retrieve Action
Storage 2-39
CCIDs updates 6-8
Structure Endevor inventory
function 1-20
about 1-7
Reverse deltas
classifying elements 1-13
about 2-39, 9-3
querying 1-15
conversion from forward A-2, A-6
setting up 1-8
conversion to full-image A-7
Structure, Endevor inventory
REXX procedure B-6
using 1-8
RLS 9-11
Subsystem
Routes
duplicate element names 5-3
establishing in the Defaults Table 3-3
element registration 5-3
types of 3-5
Subsystems
cloning definitions 2-23
S defining 1-11
Samples definition of 1-7
CCID definition data set 6-16 Definition panel 2-26
REXX procedure B-6 Request panel 2-26
Security Suggested naming standards 2-38
about 1-23 Symbolics 2-40
native 1-23

X-6 Administration Guide

System Updating
cloning definitions 2-23 Add Action CCIDs 6-6
converging within a route 3-7 CCIDs with Update Action 6-7
defining 1-10, 2-16 Delete Action CCIDs 6-10
definition of 1-7 Generate Action CCIDs 6-8
duplicate element names 5-3 Move Action CCIDs 6-9
element registration 5-3 Restore Action CCIDs 6-11
identifying 2-4 Retrieve Action CCIDs 6-8
requiring CCIDs for 6-4 Transfer Action CCIDs 6-9
tuning 9-14 User
System Definition 5-3, 5-4 exit program B-5
SYS/SBS Reg. Sev Options Menu 8-2, 8-4
System Definition panel Using
cloning 2-24 definition data set 6-15
fields 2-18—2-22 inventory structure 1-8
using 2-17 panels 2-2
System Request panel 2-16 panels to define a map 3-4
Point in Time Recovery 9-9
Subsystem Definition panel 2-27
T System Definition panel 2-17
Table Defaults 1-3, 3-3 Type
Text editor 6-15 Data Set Request panel 2-46
Transfer Action Definition panel 2-31
CCIDs updates 6-9 Request panel 2-30
function 1-20 Sequence Request panel 2-42
with history 6-10 Utilities
without history 6-9 BC1JRELD A-5
Tuning BC1JVALD A-5
processors 9-13 BC1PNCPY 9-8
system 9-14 CONWRITE 9-3, 9-13
Type Reload A-5
adjust definitions A-4 Validate A-5
cloning definitions 2-23
Data Set Request panel 2-46
Data Sets panel 2-47 V
defining 1-12, 2-29 Validate utility A-5
definition of 1-8 Validating CCIDs 6-13
Definition panel 2-31, A-4 VSAM
naming conventions 2-38 file processing 9-9
Processing Sequence panel 2-43 LOG attribute 9-11
Request panel 2-29 record level sharing (RLS) 9-11
routes 3-5
Sequence Request panel 2-42
updating data set definitions 2-46 W
WITH HISTORY A-7
Working with elements 1-19
U
Unloading elements A-4
Update Action
CCIDs 6-7
function 1-20

Index X-7