Automated Configuration

Contents
ce18
 
Contents
 
 
 
2
 
 
 
CA Endevor® SCM
 Automated Configuration (ACM) works with 
CA Endevor
 Change Manager (
CA Endevor
) to enable you to manage, through advanced automated technology, the interrelationships between software components.
To use 
CA Endevor® SCM
 Automated Configuration Manager (ACM), it is assumed that:
  • The 
    CA Endevor
     system has been installed in accordance with the instructions provided in Installing.
  • You have an understanding of the 
    CA Endevor
     environment in your organization.
  • You have an understanding of software inventory management and application migration techniques.
Software Configuration Management
A typical software inventory is composed of numerous application programs and the components -- the common code (such as COBOL copybooks, Assembler macros, and CALLed subroutines) -- which make up those programs. The discipline of managing the interrelationships between programs and their associated components is named 
software configuration management
.
When a program is translated (for example, compiled, link-edited) from source to executable, all of the components which make up that program are extracted by language translators and/or linkage editors from their resident libraries, such as copylibs or maclibs. The major challenge is ensuring that the relationship between a program and its related components is accurate and up-to-date, at any given point in time. This synchronization is typically accomplished by retranslating a program each time one of its subordinate components is changed. A problem arises, however, when a component is changed but that modification is not propagated to all affected programs.
The lack of automated, reliable methods for coordinating program-component relationships has created major obstacles to software development and maintenance. Manual definition of program-component relationships is error-prone and time-consuming by today’s standards. In addition, manual methodologies do not yield the level of component detail (version/ level/ location) needed to accurately plan and stage application development activities.
Traditional approaches to software configuration management have been severely limited in their ability to produce accurate and reliable results. Source scanning techniques, while an improvement over manual definition, provide only a static "picture" of the program-component relationship. This picture may not relate to the actual state of the software at the time of program translation. Source scanning is a separate operation that is run independently of the compile process and, as such, is only accurate at the time of the scan. Furthermore, scanning neither stores historical information nor provides the level of detail that is needed to analyze and perform configuration management functions.
Building on advanced monitoring and data storage technology, ACM overcomes the shortcomings inherent in traditional approaches to change control and configuration management. ACM monitors the libraries that house program components and automatically captures related components during the translation process. ACM then stores this information using expert base/delta technology to help in determining changes to components from one translation to the next. Unlike source scanning, ACM works as an integral part of the translation procedure to track program components automatically over time.
The following shows how ACM works to automatically track program components over time.
Software Configuration Management
Software Configuration Management
As previously shown, when activated, ACM forms an "envelope" around the translation process (for example, compiler or linkage editor). When the program or module is executed under an 
CA Endevor
 processor, ACM tracks all requested change activity and application program-component relationships. Module interrelationships are automatically captured as part of the translation procedure. Optionally, this information can also be automatically stored in Root and Cross-reference data sets for "where-used" analysis.
ACM Facilities
The following facilities are supplied with 
CA Endevor
 ACM:
  • Component Monitor
  • Component List
  • Displaying Component Data and Batch Reporting
  • Software Control Language (SCL) Enhancements
  • ACM Query Facility
Component Monitor
The ACM Component Monitor is invoked by adding a special "MONITOR=COMPONENTS" keyword to DD statements in a 
CA Endevor
 processor. Monitoring is performed on a data set basis. Once initiated, components that are used from the specified data sets are automatically tracked by ACM’s Component Monitor.
The processor keyword MONITOR cannot be specified on DD statements that refer to USS path and file names.
Component List
The 
CA Endevor
 ACM Component List provides a detailed "snapshot" of all the components from monitored data sets at the time of program translation. The Component List provides five types of information: element, processor, symbol, input, and output.
  • The element information describes the program being generated.
  • The processor information describes the 
    CA Endevor
     processor that is used to generate or move the element.
  • The symbol information identifies the user-defined symbolics that are used in the 
    CA Endevor
     processor, and their values.
  • The input components identify (by step, DDname, dsname, and volume) the component items that are referenced and any footprints that existed in a monitored data set.
  • The output components identify (by step, DDname, dsname, and volume) the members that were created during processor execution.
The first time ACM monitoring is enabled for an element, a "base" component list is stored. This component list contains all of the aforementioned element, processor, input, and output information. Subsequent generations produce new component lists which ACM internally compares to produce "delta levels." (A new delta level is stored only when one or more items change in the component list.) This base/delta architecture makes it possible to compare component list changes from compile to compile. With this information, you can quickly determine what has changed because the last compile, and greatly reduce debug time.
 
Component List Level Numbers
—The level numbers that are assigned to a component list (component levels) are independent of the level numbers that are assigned to an element (element levels). Because an element may be recompiled many times due to copy or macro changes, there may be more component levels than element levels. In addition, monitoring may be initiated at any time and at any element level. For example, an element at level 77 has a component list at level 0 when it is first enabled for monitoring by ACM.
ACM remembers up to 97 generations of a component list by default. When level 97 is reached, component levels 50-96 are renumbered as 0-49, and the previous (old) levels 0-49 are deleted. In this way, the component list functions like a circular storage vehicle. You are guaranteed that the last 50 "translations" are remembered by ACM if you use the default. You can set the number of generations that are remembered by ACM to a number lower than 97.
Component Data and Batch Reporting
 
CA Endevor
’s element display facility enables you to view configuration information online. Using this facility, you can view the current level of a program and its related components, the component changes from one compile to the next, and the complete change history of a program and its components over time. All Foreground Query options (Component Summary, Component Browse, Component Changes, Component History) are also available in batch through the SCL PRINT command.
Software Control Language (SCL) Enhancements
Expanding on 
CA Endevor
 batch processing language, SCL, ACM enables you to "implode" and "explode" information in a component list through a special LIST command. This command produces valid syntax which can further be used to perform 
CA Endevor
 actions such as GENERATE, MOVE, and ADD. The LIST command performs the function of cross-referencing a low-level component with all higher level "owners."
ACM Query Facility
The ACM Query Facility provides the capability to perform "where-used" queries quickly against ACM component data. This facility utilizes the information that is stored in the Root and Cross-reference data sets to provide this analysis. This data is dynamically updated during processor execution or loaded at regular intervals by your system administrator.
 For more information about the ACM Query Facility, see ACM Query Facility.
ACM Operational Areas
Operationally, ACM can be divided into three distinct areas:
  • Data collection
  • Data storage
  • Software configuration analysis and management
The following figure illustrates how the different areas work within ACM.
Three Areas of Operation
Three Areas of Operation
In these areas, you can see how data definition and collection starts in the ACM Component Monitor, data storage continues in the ACM Component List, software configuration analysis and management flows to the Root and Cross Reference Data Sets, and finally to the ACM Query Facility.
The ACM Component List includes the following components:
  • Element
  • Process
  • Inputs
  • Outputs
Each of these components can have the following properties:
  • Name
  • Location
  • z/OS Inventory Classification
  • Footprint
Data Collection
Data Collection begins when you invoke ACM through the MONITOR=COMPONENTS parameter in an 
CA Endevor
 processor. With this parameter, you specify the libraries and data sets that are to be monitored automatically by ACM. Then, the Component Monitor tracks all change activity and program-component relationships for the data sets you earmarked for monitoring.
The processor keyword MONITOR cannot be specified on DD statements that refer to USS path and file names.
Data Storage
ACM produces a component list during program translation (compilation), thus beginning the data storage process. The component list is an internal data structure which assembles all program-component information, with an audit stamp or "footprint" for each component, at the time of each compile. Component list "levels" (differences in component lists from one translation to the next) are stored in 
CA Endevor
 base/delta format. The component list provides a "snapshot" of a program at compilation -- identifying an element components, where they originated, their version and level, and the output that is created as the result of the translation.
 
Example
 
The following figure illustrates how ACM stores and remembers the components that are used to create the outputs for a particular generate date and time, version, and level of a typical COBOL program -- PROGRAM X -- as transformed by the 
CA Endevor
 processor COMPLINK.
Data Storage 2
Data Storage 2
 
The ACM Component Monitor has captured all the components of PROGRAM X, with the 
CA Endevor
 footprint information associated with those components. The resulting component list provides an integrated view of all configuration information relating to PROGRAM X at the time of the translation. The following table lists the Endeavor ACM components in the preceding figure:
Component
Name
Version/Level
Footprint Info
Processor
step
Library or DSN
ELEMENT
PROGRAM X
v 1.3
 
 
PROCESSOR
COMPLINK
v 1.8
 
 
INPUT
COPYRECA
v 2.1
COMPILE
COPYLIB1
INPUT
COPYRECB
v 2.5
COMPILE
COPYLIB2
OUTPUT
PROGRAM X
v 1.3
COMPILE
OBJLIB
OUTPUT
PROGRAM X
v 1.3
LINK-EDIT
LOADLIB
Footprint information can include the following items:
  • SITE ID
  • ENVIRONMENT NAME
  • SYSTEM
  • SUBSYSTEM
  • ELEMENT NAME
  • ELEMENT TYPE
  • VERSION/LEVEL
  • STAGE NUMBER
  • GENERATE DATE/TIME
Software Configuration Analysis and Management
Through the component list and the information that is stored in the Root and Cross-reference data sets, it is possible to initiate 
CA Endevor
 actions and make online inquiries. When viewed over time, this information provides a historical audit trail of component changes which serves as the foundation for all software configuration analysis and management activities, including:
  • Analyzing system behavior
  • Propagating a component change to all affected programs
  • Validating a system for consistent use of components
  • Recreating past program versions
  • Moving related source components during promotion to production
  • Providing "where-used" analysis