Change Control

Applications typically undergo extensive modifications as companies customize and fine-tune software systems to meet their specific business requirements. Given the sheer volume of change requests in today's IT organization and the growing demand for more effective ways of tracking and documenting development change activity, manual change control procedures can no longer be relied upon to produce the accurate, reliable information needed to identify problems, track projects, and analyze the impact of change.
18-0
Applications typically undergo extensive modifications as companies customize and fine-tune software systems to meet their specific business requirements. Given the sheer volume of change requests in today's IT organization and the growing demand for more effective ways of tracking and documenting development change activity, manual change control procedures can no longer be relied upon to produce the accurate, reliable information needed to identify problems, track projects, and analyze the impact of change.
2
Automated Change Control
Endevor
forms an envelope around your application environment and captures all change events, enabling you to identify what was changed, who made the changes, when, and why. Because
Endevor
performs change control functions automatically, the resulting information is accurate and current.
Identifying and Tracking Changes
As a prerequisite to understanding, controlling, and auditing the software environment, change control systems must be able to identify changes as they occur, then further pinpoint when the changes were made, by whom, when, and why.
  • CCIDs
    Endevor
    Change Control Identifiers (CCIDs) provide a means of grouping and manipulating similar kinds of change activity. For example, a number of different elements (COBOL copy members, COBOL programs, and so forth) can be included in a single change request. By tagging each of those changes with a common CCID (such as FIX01), every change made for that change request is categorized as belonging to that CCID. Subsequently, the CCID can be used to identify and manipulate all the elements within the change request. For example: Move all elements for COD FIX01 from Unit Test to System Test. CCIDs can also be predefined and validated for change administration purposes.
  • Change History
    Endevor
    automatically captures and dynamically tracks all source changes by creating a unique delta to record each change event. An element's delta levels identify not only the actual lines of code that have been changed, but also user, comment, CCID, and date and time information for that change. The result is a complete and accurate history or audit trail of application change activity.
  • Regression Notification
    In parallel development situations where many individuals work on the same module concurrently, change regression occurs when one individual unintentionally negates (rather than incorporates) the changes made by another individual. When unchecked, regression can be a major cause of production failures. During action processing,
    Endevor
    performs a regression check and notifies you when regression has occurred, allowing you to quickly pinpoint and correct the situation before it adversely affects the production environment.
  • Signin, Signout
    To avoid possible regression during parallel development,
    Endevor
    provides signin/signout security at the element level. This optional capability is enabled on a system-by-system basis. When the facility is enabled, elements are signed out as they are retrieved. While other users can retrieve copies of those signed out elements, they cannot update those copies within
    Endevor
    without explicitly overriding the original user's signout. Only authorized users can exercise the explicit override feature.
  • Activity Logging
    A complete log of all activity within
    Endevor
    can be written to a variety of data structures, including standard SMF records. This information, available online and in hardcopy format, provides a high level audit trail of change events which can be used to determine change patterns over time.
Automating Processes
In application development, a procedure or process is the set of steps used to transform source language statements into executable code. Some inventory elements, such as those written in 3rd generation languages (COBOL, Assembler, C, PL/I, and so on) have straightforward processes that compile the source and link-edit the object. Other element types require more complex processes, such as the resolution of data base calls or the automated generation of textual documents. Because these processes ultimately determine how an element will interact in production, the management of these procedures is critical.
One of the powerful facilities provided by
Endevor
involves the regulation and control of all transformation processes through automated procedures called processors.
Endevor
processors are written in job control language (JCL) statements that specify process steps, parameters, error conditions, data set names, output libraries and the like.
Once defined, processors can be used to automatically carry out a variety of procedures and create the outputs associated with application elements. Element types within the inventory classification determine the appropriate processors. For instance, elements that are written in COBOL are typically handled by the COBOL compiler and linkage editor, while elements that are classified as copy members are usually validated and copied to a specific location.
  • Automated Output Generation
    Endevor
    processors are often used to automate the procedures that generate outputs from source. As illustrated in this diagram, you can create a processor for Batch COBOL programs that automatically performs a COBOL compile and link-edit into the Finance system's load library, and stores the listing in the Finance system's listing library.
    Automated Output Generation
    Automated Output Generation
  • Automated Promotion Procedures
    A processor can also contain procedures for promoting applications throughout the development lifecycle. When
    Endevor
    is instructed to perform a promotion, it reads the processor definition to obtain directions about the promotion procedures specified for a selected element type. Those procedures are then uniformly invoked by
    Endevor
    . When promoting a Batch COBOL program within the Finance system from Testing to Production, for example, a MOVE processor can be defined which contains instructions for automatically copying the load modules from the Test load library to the Production load library.
  • Automated Backup and Recovery
    In addition to automating the procedures used to generate outputs from source and promote applications throughout the development lifecycle, processors can be defined to execute emergency backup and recovery procedures. For example, a MOVE processor can contain a step that automatically copies production load modules to a backup library. A recovery procedure can additionally be defined to copy that module from the backup library into an emergency library in the event of a production failure.
How to Establish Source-to-Executable Synchronization
To effectively and accurately maintain, debug, and audit software, you must be able to link executable code back to its originating source.
Endevor
achieves this goal by controlling the processes by which outputs are created from the source, and further ensures source-to-executable synchronization by audit stamping or footprinting those outputs.
  • Process Control
    Endevor
    's automated processors ensure that the source-to-executable link is not compromised, by tying the process used to create outputs directly to the manipulation of the source. Frequently, load modules and their associated source are processed at different points in time, presenting a precarious window in which a change to one causes an out-of-sync condition. When source is presented to
    Endevor
    , the outputs are automatically created from the current source through the use of automated processors. When source is moved through the development lifecycle,
    Endevor
     automated processors ensure that the load modules and outputs are manipulated together with the source, rather than through separate procedures.
  • Footprints
    Footprinting is a change control technique employed by
    Endevor
    to maintain synchronization between source and its related executable. During element processing,
    Endevor
    places an encrypted audit stamp called a footprint in the output source, object, or load modules that are created. Only
    Endevor
    automatically builds footprints as an integral part of the source-to-executable transformation process.
    • Endevor
      footprints contain the following information:
    • Location information
    • Element name
    • Element type
    • Element version/level
    • System and subsystem to which the element belongs
    • Date/time the footprint was assigned
Endevor
employs standard operating system facilities to store its footprints, thereby ensuring compatibility with present and future operating systems. In a PDS, for example, the footprint is stored in the user data area of the directory; in
Librarian
, as a history record; in
Panvalet
, as a comment field; in a load module, in the user IDR record for the CSECT.
All data structures managed by
Endevor
(source libraries, copy libraries, executable libraries, and processor listing libraries) contain footprinted elements. Footprints can be used to validate the source-to-executable link of an entire load library. And because
Endevor
footprints uniquely identify the versions/levels of input components, they play a key role in configuration management. This diagram provides a high-level view of how automated processors and footprints work together:
Establishing Source to Executable Synchronization
Establishing Source to Executable Synchronization
As shown in the previous illustration:
  1. The source is built from the 
    Endevor
     internal base/delta format, and a footprint representing that element's source is created and made available to subsequent steps in the
    Endevor
    processor; the source is compiled.
  2. The output object from the compile is stamped with a footprint before being passed to the next step.
  3. The linkage editor links the program into the appropriate load library.
  4. The listings from the previous steps are combined and stored (also with a footprint) in the appropriate listing library.
Audit Management
As valuable corporate assets, applications cannot be compromised when it comes to integrity, reliability, and recoverability. For this reason, applications must be controlled and secured in a way that meets stringent auditability requirements. The 
Endevor
 automated change control functionality fully satisfies the scope of an audit and provides the necessary platform for producing management reports that can be used to evaluate software integrity.
Endevor Actions
Endevor
performs software management operations through user-invoked actions. All actions can run in foreground (online) and background (batch) modes, except for the Archive, Alter, Restore, Transfer, and Validate actions. The actions are as follows:
  • ADD
    The action used to introduce an Element into an
    Endevor
    environment.
  • ALTER
    This action replaces Master Control File Element metadata with user-specified values. The Alter action is not available from the Foreground Options menu. Alter statements can be submitted from the Batch Options menu.
  • ARCHIVE
    The action used to copy an Element and all of its change history and control information from an
    Endevor
    environment to an external data set. Archive can only be run in batch mode.
  • DELETE
    The action used to remove an Element from an
    Endevor
    environment.
  • GENERATE
    The action used to execute the
    Endevor
    automated processor for an Element.
  • LIST
    The action used to scan members in a library or the
    Endevor
    inventory to generate a list of Elements that meet specific selection criteria.
  • MOVE
    The action used to promote an Element from stage to stage within an
    Endevor
    environment.
  • PRINT
    The action used to produce hardcopy output of
    Endevor
    Element, change, change history information, and Element output listing.
  • RESTORE
    The action used to re-introduce an Element to
    Endevor
    from an archived data set. Restore can only be run in batch mode.
  • RETRIEVE
    The action used to copy any level of the source of an Element from an
    Endevor
    environment into an external data set.
  • SIGNIN
    The action used to remove the user signout associated with an Element.
  • TRANSFER
    The action used to transport an Element from one location to another, where each location can be an
    Endevor
    location or an external data set. Transfer can only be run in batch mode.
  • UPDATE
    The action used to create a revision of an Element in an
    Endevor
    environment. When applicable, these actions drive the automated processors that have been defined to
    Endevor
    . Before an action is executed by
    Endevor
    , a security check confirms the user's authority to perform that action upon the requested Element. All actions and their results are reflected in
    Endevor
    execution processing reports.
  • VALIDATE
    The
    Validate
    action performs element master, synchronization, and component validation checks against the element you specify. These inventory validation checks can be performed at any time, enabling developers to ensure the integrity of elements before including them in a package. This is a batch only action and is not supported in a package.
Software Control Language (SCL)
The tedious and repetitive tasks associated with manipulating the software inventory are time-consuming and prone to error. The 
Endevor
 Software Control Language (SCL) is a powerful yet simple language which, when combined with
Endevor
actions, eases the burden of manipulating and moving portions of the software inventory throughout the entire development lifecycle.
SCL Capabilities
SCL saves substantial amounts of time by enabling you to work with as many (or as few)
Endevor
actions as are required to complete a specific job. With SCL, you can do the following:
  • Perform bulk data manipulation.
  • Set up a single list or multiple lists of actions for manipulation by
    Endevor
    .
  • Establish standardized global settings for action requests.
  • Process actions in inventory type sequence order, automatically sorting elements according to specification.
  • Generate software configuration lists based on different selection criteria.
  • Use a single scan facility that will run against
    Panvalet
    ,
    Librarian
    , a PDS, and
    Endevor
    , eliminating the need to use separate utilities to scan source code.
  • For problem-solving purposes, generate a list of only those elements that were not successfully processed at a specific time.
  • Write user-defined front-ends for various vendor-supplied programs.
  • Integrate
    Endevor
    into existing job scheduling systems.
SCL can be generated and manipulated through online screens, providing an easy-to-use, flexible environment for executing software procedures. Using SCL, repetitive tasks, which normally require significant amounts of time, can be accomplished with very little effort.