is a software change management tool used to control (secure, manage, and track) changes to an organization's software inventory.
is highly customizable.
The product must be configured to support a logical software development lifecycle and inventory structure, which is described using the following terms:
  • Element
    — Members of data sets that have been placed under the control of
    . Each Element is identified by a fully-qualified name consisting of its location in the lifecycle (the environment and stage combination) and its classification (System, Subsystem, and Type) and Element name. Users perform actions against Elements. If an Element is changed, a new level of the Element source is created. The current level of the Element includes the latest changes. Earlier levels can be viewed, compared, and restored if necessary.
  • Actions
    — Commands used to management Elements. Actions include Add, Archive, Copy, Delete, Display, Generate, List, Move, Print, Restore, Signin, Transfer, Update, and Validate.
Logical structure
  • Lifecycle
    -- Defines the location and flow of the inventory in the development or maintenance process (for example, your code is either in development, QA, or production).
    • Environment
      — Logical work areas. An
      is the top level of the logical structure used to classify elements in
      . Environments usually correspond to functional levels in an organization (for example, development, quality assurance, and production). Each environment has two stages.
    • Stage
      — A stage in the software lifecycle. Two stages are defined for each Environment.
    • Lifecycle location
      -- Defined as an Environment and Stage combination, which indicates the area in the lifecycle where an Element resides. A typical simple lifecycle includes the following areas, known as Environments: development, QA, and production. The software code that is currently in use, resides in the production Environment. So, when a developer needs to make a change, they retrieve the code from the Production Environment back to the Development Environment. Then the code is moved to the QA Environment, and then to Production Environment. The typical simple lifecycle includes the following Environment and Stage combinations:
  • Development Stage 1 (DEV S1)— The unit test stage, of the development environment where sandbox Subsystems can be added for development of code changes.
  • Development Stage 2 (DEV S2)— The unit test complete stage, of the development environment where the code changes developed in stage one can be moved when completed and awaiting promotion to QA S2.
  • QA Stage 1 (QA S1)— Stage 1 of the quality assurance environment that is used
  • QA Stage 2 (QA S2)— Stage 2 of the quality assurance environment that is used for the integration of code changes and QA certification.
  • Production Stage 2 (PRD S2)— Stage 2 of the production environment that is used for production or published PTFs.
  • Lifecycle Map
    -- Stages are mapped to define the route of the inventory through the lifecycle as development (or maintenance) activity progresses. For example, using the Environment and Stage combinations shown in the previous example, the stages would be mapped to allow the inventory to be moved from stage to stage in the following order: DEV S1-->DEV S2-->QA S2-->PRD S2
  • Inventory classification
    -- Classifies Elements by System, Subsystem, and Type. Systems and Subsystems are defined to Environments and typically represent software applications and different versions of those applications. So, a lifecycle for a bank, might include two versions of an online banking application that would be defined to all the Environments. This would allow it to be control by Endevor from Development, QA, and production. Types, which control processing of Elements, are defined to Environment-Stages.
    • System
      -- Specifies a software application that is defined to an Environment. Typical values follow:
      • A one- to five-character product identifier for the development code line. For example, to identify the development code line for a software application called "Online Banking," the System might be named: ONLB
      • A one- to five-character product identifier plus a release number (xxx) for a GA software application release code line. For example, if the GA software is release 14.0, the System name might be: ONLB140
    • Subsystem
      -- Specifies a subgroup for a System defined to an Environment, usually a version of a software application. The Development Environment might include multiple Subsystems all of which are mapped into one Subsystem in the QA Environment. For example, a System might have two Subsystems named as follows: DEVEL, to specify a development release code line, and MAINT to specify a GA code line. The Development Environment might have a Subsystem for each enhancement that is being made to the application. Then those fix Subsystems map into the DEVEL Subsystem when they moved into the QA Environment.
    • Type
      -- Specifies an Element class that is defined for an Environment-Stage location, usually a programming language. Typical Types follow: ASMMAC, ASMPGM, CHDR, CPGM, COBCOPY, COBPGM, ISRC, ISPM, ISPP, ISPS, JCL, LNK, LNKINC. Two of the Type definition parameters are:
      • Element delta format
        — Determines how changes to Elements of the same Type are stored. Every time an Element is changed a new Element level is created. Each Element in a particular Stage can have a base level and multiple delta levels, depending on the format. The administrator allocates data sets to store the base and delta Elements.
        The element Type storage formats are compared in this table:
        Element Format
        Current Level
        Prior Levels
        Element Base Level
        Delta Level Files
        Reverse delta
        Complete image
        Current level
        Show changes between each level.
        Forward delta
        To create the current level, all the delta levels are applied to the element base.
        The image is as it was first added to
        Show changes between each level.
        Image delta
        Complete image
        Current level
        Each delta file is a complete image, because changes between levels are not compared.
        log delta
        Complete image
        Current level
        Each delta file contains change information, but not source code changes. Data in the Source Level Information area in an element browse and summary display comes from information stored on the change level delta records.
      • Processor groups
        -- Specifies a subgroup of Type. Processor groups are associated with a Type and specify how an Element of that Type is processed. A Processor Group includes Generate, Move, and Delete processors, which are JCL programs that are invoked depending on whether the Element is being generated, moved from stage to stage, or deleted.
Physical structure
  • Master Control File
    — Stores the Systems, Subsystems, Types, and Element definitions that are defined to a particular Stage. This file is accessed and updated by
    to manage the Element definitions, to execute Processors, and for other miscellaneous functions. There is one Master Control file for each Stage. The name of the file that corresponds to a particular Stage is specified in the Defaults table, C1DEFLTS.
  • Package
    — A group of
    actions that requires approval before it can be executed. Creating packages allows the user to group specific actions so they can be maintained and tracked as a single unit, establish formal approval procedures to ensure data integrity through modifications, and centralize specific action groups so you can see them across environments and reuse them.
  • Package Data Set
    — Where package definitions are stored. There is one package data set for an environment.
Related features
  • User exits
    provides logic points that can invoke a program that runs outside of the control of
  • Footprints
    — Metadata added to individual source, object, or load modules, to identify the Element associated with that module.
  • Configuration files
    — Assembler source modules enable the
    administrator to customize the implementation.
    • C1DEFLTS--The Defaults table contains site-wide information including
      control data set names, and settings available for
      features, and the names of other configuration tables.
    • The following table describes each table and identifies the corresponding C1DEFLTS parameter in the Defaults table.
      Delivered Table Name
      C1DEFLTS Parameter
      ESI Security Definition Table
      Defaults Table
      Authorized Program Table
      Language Definition Table
      ++CONTOL Password Interface Program
      User Exits Table
      Optional Features Table
      ISPF Configuration Table
      Email ID Table
      Site Symbolics Table
Example: Sample Product Maintenance Lifecycle for a Software Application
This graphic illustrates a sample lifecycle for the development and maintenance of a software application for Online Banking.
  • In the top row is System ONLB that identifies that this is the development code line (trunk) for the Online Banking application
  • The bottom two rows are GA code line (branches):
    • ONLB140 is the System name, which identifies the GA code branch for the Online Banking application code for release 14.0.
    • ONLB150 is the System name, which identifies the GA code branch for the Online Banking application code for release 15.0.
  • The arrows between the stages indicate how the stages are mapped to move the software inventory from stage to stage. The mapping is predefined in the Defaults table configuration file as: DEV S1-->DEV S2-->QA S2-->PRD S2
  • For both GA code lines:
    • The arrow with solid lines indicate the build of the GA Code branch from the PRD location of the Development trunk when the GA candidate is created.
    • The arrows with dotted lines indicate the published maintenance artifacts being transferred to the Subsystem of the same release.
AUDITProduct Maintenance lifecycle.png