Impact of ENDEVOR on SDLC

ENDEVOR
ENDEVOR is an integrated set of management tools used to automate, control, and monitor your applications development process. ENDEVOR runs under MVS, within the TSO/ISPF environment, and in batch.

Using ENDEVOR, you can:
· Track your changes against production, creating an online change history, enabling you to know what was changed, by whom, when, and why.
· Prevent conflicting changes to the same system component.
· Browse and manipulate all components relating to an application from a
· a single screen, saving you time.
· Automate executables creation.
· Ensure that the source, executable, and any other form
· (for example, listings) of an element correspond.
· Apply the same procedures (including automating compiles, impact
· Analyses, and standards checking functions) to any component type.
· Put change packages and approvals online, eliminating paperwork.
· View or retrieve prior levels of any element.
· Report on element definition, content, and change history.
· Enforce change control procedures.

Software Life Cycle :

ENDEVOR allows you to automate and control the movement of software through your software life cycle. Life cycles are site-specific. A representative life cycle might consist of five stages:
* DEVELOPMENT - Programs are developed.
* TEST - Programs are unit tested.
* QA - Applications are system tested.
* EMERGENCY - Fixes are applied to production code.
* PROD - Production applications reside.
The ENDEVOR administrator might decide to put the TEST, QA, EMERGENCY and PROD stages under the control of ENDEVOR.
Basic :
Normal change procedures include:
* Retrieving from production to a development library.
* Making changes.
* Adding/updating into the test stage.
* Moving to QA.
* Moving back into Production.
<------------- retrieve -----------------------------------
******** ******** ******** *******
* TEST * * QA * * EMER * * PROD *
* * * * * * * *
****** ****** ******** *******
$$$$$$$
$ dev $ - move --> -------- move -------------->
$ --add->
$$$$$$$$

Emergency : Emergency change procedures include:

* Retrieving from production.
* Making changes.
* Adding/updating into the emergency stage.
* Moving to Production.
---- move ------->
******** ******** ******* *******
* TEST * * QA * * EMER * * PROD *
* * * * * * * *
******** ******** ******* *******
add $$$$$$$ retrieve
$ dev $
<----- <----
$$$$$$$$

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,
you can list all COBOL code in your shop, or promote an entire new release of the payroll application with a single command.
ENDEVOR can produce lists, for example, of:
* All the JCL in the shop
* All the software currently in QA
* All the manufacturing software currently being unit tested
There are many other ways to use this structure to your advantage.
Job Function
*---------------------------------------------------*
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
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
*-------------*---------------------------------------------------*
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. The actual inventory is made up of elements. Users act on elements.

1 - Environments 5 - Types
2 - Stages 6 - Elements
3 - Systems 7 - Using the inventory structure
4 - Subsystems 8 - The software life cycle

Environment :

Environment is the ENDEVOR term for the functional areas of 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. Environments are defined in the C1DEFLTS table. Environment information can be viewed on the Site/Environment Information panel.

Stage :

Stage is the ENDEVOR term for a stage in the software life cycle. For example, a site may have stages TEST, QA, FIX, and PROD in its life cycle There must be two stages for each environment.
Stages have a name, representing their place in the life cycle (for example TEST) and an ID (1 or 2). Stages are referred to as Stage 1 (the first stage in an environment) and Stage 2 (the second stage in an environment).
Stages are defined in the C1DEFLTS table. Stage information is displayed on the Stage Information panel.
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.
1 - Stage information panel 2 - Mapping
Current env - Name of the environment for which stage information is shown.
Next env - The name of the next environment on the map.
Stage ID - ID of the first Stage in the next environment.
Stage 1 and 2 Information.

ID - Stage ID.
Name - Stage name.
Title - Stage description.
MCF data set name - Data set name of the Master Control File for the Stage.

Part of implementing ENDEVOR is to define the stages in the software life cycles at your site, then organize these stages into environments. See Chapter 1 of the Administrator's Guide.

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 automate the adding, displaying, retrieving, moving, and generating of inventory in a given life cycle.
1 - One route map - example 5 - The map and actions
2 - Two route map - example 6 - The map and lists
3 - Establishing routes 7 - The map and signout
4 - Mapping inventory locations 8 - Implementation checklist

1 - One route map - example
In its simplest form, a series of environment/stage locations can be
chained together to form a one-route map.

***************** ***************** *****************
* DEV * * QA * * PROD *
***************** ***************** *****************
* UNIT * INT * * QA * HOLD * * FIX * PROD *
* * * * * * * * *
* -----> -----------> -----> ----------------------> *
* * * * * * * * *
***************** ***************** *****************

2 - Two route map - example

Route R1 (DEV, QA, and PROD) for production applications.
Route R2 (QFIX, PROD) to handle emergency fixes to the applications.

***************** ***************** *****************
* DEV * * QA * * PROD *
***************** ***************** *****************
* UNIT * INT * * QA * HOLD * * FIX * PROD *
* * * * * * * * *
R1 * -----> -----------> -----> --------------------> , *
***************** ***************** ****************

********************
* QFIX *
********************
* TSTFIX * PREPROD *
R2 * -----> ------------
********************
System :
System is the ENDEVOR term for the applications at a site. For example, a site might have financial (system: FINANCE) and manufacturing (system: MFG) systems.
A system must be defined to each environment where it will be used. You work with systems using the System Definition panel. You can clone system definitions within or across environments using the
System Definition - Clone panel.

1 - System definition panel 2 - System definition – clone

Subsystem is the ENDEVOR term for a particular application within a system. For example, there might be purchase order (subsystem: PO) accounts payable (subsystem: AP) applications within system FINANCE.
* There must be at least one subsystem per system.
* A subsystem must be defined to each system in which it will be used.
For example, if you plan to have subsystem PO within system FINANCE, and define system FINANCE to environments TEST, QA, and PROD, you must also define subsystem PO to system FINANCE in each environment.
* A subsystem can have the same name as the system to which you
define it.

Subsystem :

You work with subsystems using the Subsystem Definition panel. Type is the ENDEVOR term for 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.

Processors :
ENDEVOR uses JCL streams called processors to automate creating executables. You can associate a group of processors with each type. Each processor group includes the processors needed for a particular type of source. For example, the processor group for type COBOL might include processors for VS COBOL and COBOL II.
You work with types on the Type Definition panel.
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.
A list of suggested naming standards for types follows. This list is not complete and is presented here as a guideline only.

ASEMBLER LINKCARD SORTCNTL FORTRAN
BASIC MACRO SPECS RPG
CLIST MARKV TABLES JCL
COBOL NETRON TELON REPORTS
COPYBOOK PLI TRNSFORM
EASYTRE VPROC UTILITY

Element is the term for PDS members, Panvalet or Librarian, or
sequential data sets that have been placed under control of ENDEVOR.
The element name defaults to the member name.

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.

Working With Elements

You manipulate ENDEVOR inventory by executing 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 ENDEVOR/MVS User's Guide explains how to execute actions in
foreground and submit batch action requests.
* The ENDEVOR/MVS SCL Reference Manual contains the syntax for
ENDEVOR's Software Control Language (SCL). SCL allows you to code
batch action requests.

Signout/signin :
Signout/signin can be enabled on a system by system basis.

Action Impact on element Options
Add/Update Signs out Override signout
Move Signs in at target Retain signout, Signout to
Retrieve Signs out Override signout, No Signout
Generate No change Override signout
(no copyback)
Generate Signs out copied Override signout
(copyback) back element
Transfer Signs in at target Override signout, Retain signout
Signout to
Archive No change Override signout
Restore Signs in at target Override signout
Signin Signs in Override signout, Signout to
Copy No change Override signout
Delete No change Override signout

Package :
A package is a set of ENDEVOR actions that may require approval before being executed. You create a package by building batch SCL streams containing the actions to be executed.

1 - Creating packages 5 - Committing packages
2 - Casting packages 6 - Package Backout
3 - Reviewing packages 7 - Package shipment
4 - Executing packages 8 - Package action/status summary

Creating a package involves:
* Identifying the elements to be included in the package.
* Building a file of actions to be performed against the elements.
* Identifying the package as standard or emergency.
* Specifying dates between which the package must be executed.
You can also create a package by reusing an existing package. After creation, a package has a status of in-edit. You can modify a package as long as it has a status of in-edit.

Casting a package :
Casting a package prepares the package for review and subsequent execution. When you cast a package, ENDEVOR:

* Determines whether approvers have been assigned to the inventory area(s) included in the package.
* Makes sure that any approvers have authority to perform the package actions against the package inventory areas.
* Checks the integrity of the package components.
* Makes sure that the package contains the most recent versions of all components.

A package cannot be edited once it is cast.

1 - Determining approvers 3 - Security checking
2 - Component validation 4 - Integrity checking

The first step in casting a package is to determine if approvers are associated with the inventory areas referenced in the package.

Action Inventory Area
Add/Update Target
Restore Target
Generate:
With COPYBACK Target
Without COPYBACK Source
Move Target
Delete Source
Signin Source
Transfer:
With DELETE Source and Target
Without DELETE Target
Archive:
With DELETE Source

If component validation is active, ENDEVOR examines the component list associated with each element specified in a Move action. ENDEVOR does not allow a package to be cast if any components
* Reside at the same stage as the source of the Move action and have not been included in the package. In this case, ENDEVOR appends commented Move SCL for the omitted input component.
* Are missing or have been modified (the time stamp in the component list footprint does not correspond to either the Generate or Move time stamp in the MCF) since the element was generated. ENDEVOR issues error messages about this condition.
When a cast fails for either of these reasons, review the package and do one of the following:
* Generate the element to pick up the latest version of a component.
* Cast the package without validation (if allowed).
* Cancel the package if a component has been deleted.
For more information, see Chapter 7 of the User's Guide.

The ENDEVOR C1DEFLTS Table contains a flag*PKGCSEC*that indicates whether action s should be checked at package cast time, to determine whether the person casting the package has the authority to perform all actions contained in that package.
If PKGCSEC=Y, ENDEVOR checks each action in the package. If the person is not authorized to perform all actions, he/she cannot cast the package. If PKGCSEC=N, ENDEVOR does not check action security.


After the package is cast, it contains either a copy of the footprint of the source element or a checksum value for source members from an external data set.
Before executing the package, ENDEVOR compares this footprint or checksum value with the values stored in the package. If any differences exist at that time, the package is not executed.

A package must be reviewed if one or more approver groups are associated with the inventory area(s) included in the package. Once a package is in the review phase, only designated approvers can access the package and review its contents.

Reviewing Packages :

To be approved, a package must:
* Receive approval from at least the required approvers.
* Receive approval from a quorum of approvers.
* Not be denied approval by any approvers

Example: The approver group PKGQA consists of three approvers. The
approver group was established with a quorum size of 2, with one approver required. This means that in addition to the required approver, one of the two remaining members of the approver group
must approve the package in order for it to be executed.

Executing Packages
The package can be either executed online or submitted in batch. The user performing the execution must be an approver and must have the authority to perform the actions contained in the pac kage.

The outputs of packages that have been executed can be backed out, backed in, or shipped to remote locations.

Committing Packages
Package processing provides you with the ability to backout and and subsequently backin, change packages. The backout/backin option is available only after you have executed a package. All package event information, as well as backout/backin data, is maintained with the package until you commit the package.

Committing a package removes any backout/backin data while retaining package event information. A package should be committed only when you are sure that you will no longer need to back it in.

Package Backout

Should you discover a problem once you have executed the package, or if the execution failed, you can back out the package. You can also reinstate backed out packages, using the back in option.
When you back out a package, you must use the BSTCOPY utility, not IEBCOPY. BSTCOPY is discussed in Chapter 5 of the Administrator's Guide.

Note: Package backout deals with ENDEVOR output libraries, not base and delta libraries. If reverse or image delta format is being used, the base library member will not be backed out.

Why backout does not affect source
Package backout is designed to restore load modules and other executables to their pre-package execution state. Backout does not restore the source to its previous image, because the "bad" source is the audit trail of the change. This audit trail should not be disrupted for any reason, because it allows you to view change history and changes only online, facilitating problem resolution.

ENDEVOR "knows" that the executables have been backed out even if the source isn't, by flagging the element in the MCF. ENDEVOR warns users who subsequently attempt to retrieve the backed out element that they are working with a backed out copy.

Note: If you want to restore the prior level of source, you can do so online using the Summary of Levels panel on the Retrieve action. The prior level of source, after retrieval, can then be added back into ENDEVOR, creating a new change level and preserving the audit trail
of the bad change.

Backout and package dependencies
As with package commitment, package backout and backin takes into
consideration dependencies between packages.

Assume you execute package PKG1, containing elements COPYA, COPYB,
COPYC, and COPYF. You then execute package PKG2, also containing
element COPYF, as well as COPYD and COPYE.

You then decide to back out PKG1. Because the execution of PKG2 has
affected element COPYF, which is in both packages, you must back out
PKG2 first. Otherwise, COPYF will not be returned to its original,
pre-execution state.

The package shipment utility uses data transmission programs to
distribute package outputs (source, object, listing, or load modules),
or package backout members from a host site to another site. It is
designed for users who develop software at a central site and want to
transmit source, object, or executable code either locally or to other
(remote) sites.

Package Shipment:
To use the package shipment utility:
* Packages must be created with BACKOUT ENABLED=Y.
* Packages must have been executed, but not committed
* One of these data transmission packages must be available
- XCOM 6.2 (CAI)
- Bulk Data Transfer (IBM) Version 2, or via NJE/NJI
- NetView File Transfer Program Version 1 (IBM)
- Network DataMover (Sterling Software)
* Remote destinations must be defined











Package Action/Status Summary
If You Do This This Status Changes To Next Action Is
Create package None In-edit Modify or cast
Modify package In-edit In-edit Cast
Cast package
Approval In-edit In-approval Review
No Approval In-edit Approved Execute
Unsuccessful In-edit In-edit Correct and re-Cast
Review package
Approved In-approval Approved Execute
Denied In-approval Denied Reset and correct
Execute package
During execution Approved In-execution
Successful In-execution Executed Backout, Backin, Ship
Unsuccessful In-execution Exec-failed correct and re-execute
Commit package Executed Committed
Backout package Executed Executed Backin, Ship
Backin package Executed Executed Backout, Ship
Ship package Executed Executed Backout, Backin, Commit


This document lists the new features and enhancements available in
Release 3.9 of Endevor for OS/390. Select 1 - 10 for information about
the following topics:

1 - Element Locking for Packages
2 - ESORT Command for Sorting ISPF Selection Lists
3 - Full-Image Delta Format
4 - GENERATE-IN-PLACE Quick-Edit Option
5 - Monocase Text Search Option
6 - Prompt for Package ID or Element Name if Omitted Option
7 - Endevor API capability to Perform Element Actions
8 - OS/390 SYSPLEX VSAM Record Level Sharing (RLS)
9 - Endevor for OS/390 Agent Technology
10 - Documentation enhancements