Configuration Management

Historically, a major deficiency in the management of software systems has been the lack of an accurate means of determining the interdependencies or configurations of applications and their related components. Semi-automated source scanning techniques have provided a partial solution. These techniques are no longer feasible, however, given the size and complexity of today's applications, the frequency of component changes, and the growing demand for a more auditable means of tracking and managing software configurations as they evolve over time.
18-0
 
 
Historically, a major deficiency in the management of software systems has been the lack of an accurate means of determining the interdependencies or configurations of applications and their related components. Semi-automated source scanning techniques have provided a partial solution. These techniques are no longer feasible, however, given the size and complexity of today's applications, the frequency of component changes, and the growing demand for a more auditable means of tracking and managing software configurations as they evolve over time.
Automated Configuration Option
Built upon a logical inventory structure and a powerful change control platform,
Endevor
provides an automated configuration management facility (ACM) that monitors and establishes accurate configuration information.
Defining Software Configurations
When a program or module is translated from source to executable, all of its related components are collected from their resident libraries (copylibs, maclibs). To keep an accurate record of changing software configurations, the process of tracking program-component relationships and associated change activity must be performed automatically as an integral part of the translation procedure.
  • The Component Monitor
    While a program or module is being translated by a processor, ACM automatically captures the program-component relationships as they are resolved from the selected data sets, as the illustration shows:
    The Component Monitor
    The Component Monitor
  • The Component List
    As output from the translation procedure, ACM automatically produces a snapshot or Component List for each monitored program. This Component List is an internal data structure that preserves a physical profile of the configuration. As illustrated next, the Component List identifies all input program components and where they originated, and the output components created as the result of the translation procedure. Footprint information, including the version and level of the component, is also noted, if present.
Configuration Type
Name
Footprint Information
Step
Library
Element
PROGRAM X
v1.3
 
 
Processor Record
COMPLINK
v1.8
 
 
Input
COPYRECA
v2.1
Compile
COPYLIB1
Input
COPYRECB
v2.5
Compile
COPYLIB2
Output
PROGRAM X
v1.3
Compile
OBJLIB
Output
PROGRAM X
v1.3
Link-Edit
LOADLIB
The element information describes the program being generated. The processor information describes the
Endevor
processor used to generate the element. The input components identify the component items referenced and any footprints that exist in the monitored data set. The output components identify the elements that were created during processor execution.
  • Storing Component Lists
    The first time a Component List is created, it is stored in its entirety as the base. Subsequent differences in Component Lists from one program translation to the next are stored as deltas (changes only) and automatically assigned a component level number. By using base/delta technology to store Component Lists, ACM enables you to compare component changes from compile to compile, a capability unavailable through source scanning techniques.
  • Viewing Component Lists
    When stored over time, Component List information becomes the basis for maintaining and viewing component history. Through online displays, ACM lets you view Component List information from four perspectives:
    • Summary of component levels
    • Current level of a component
    • Component changes
    • Component history
Using Software Configurations
Using the information contained within Component Lists, you can reate a selection list. In this diagram, a selection list has been created by using
Endevor
to LIST all programs WHERE COMPONENTS EQUAL 'COPYRECA':
Use Software Configurations
Use Software Configurations
As a cross-reference facility, the LIST action, with selection lists in SCL format, provides the necessary foundation for performing a number of essential configuration management functions.
  • Propagating Component Changes to Related Programs
    When a component is changed, it is necessary to propagate those changes to all affected programs. Using the LIST action, you can perform change impact analysis by identifying every program containing that changed component. And you can also use the resulting selection list to perform bulk data manipulation by re-compiling those programs, all at the same time, to reflect the change.
  • Validating a System for Consistent Use of Components
    To prevent production failures, it is desirable to validate that all programs are using the correct component versions/levels. Execution reports from LIST action execution, in combination with selection lists, can be used to identify inconsistencies.
  • Re-Creating Past Configurations
    It is sometimes necessary to recreate a program exactly as it has existed at a past point in time. Using the LIST action, you can recreate an older version/level of a program's load module that includes the old versions/levels of all related components used at the date/time the load module was originally created.