Endevor and DB for Bridge

The Bridge aids Endevor SCM users in the release management process by giving them access to the capabilities inherent in a database environment.
The Bridge aids Endevor SCM users in the release management process by giving them access to the capabilities inherent in a database environment.
Using Endevor SCM, you can track the history of an inventory element at the source. With the addition of the Bridge, you have access to the migration data for an inventory element and can obtain the following information:
  • The identity of promoted elements and entities.
  • The origin of promoted elements and entities (source).
  • The destination of promoted elements and entities (target).
The Bridge allows you to log Endevor SCM activities in a Endevor/DB for IDMS Change Control Database (CCDB) and to perform release management functions that enable you to monitor your development activity and maintain the integrity of your systems.
Bridge Functions
You can perform the following functions with the Bridge:
Track the migration of an inventory element from one environment to another. For example, you can track the migration of an inventory element from a development to a production environment.
Track and review changes to dictionary and non-dictionary entities from a central location. That is, you can log all Endevor SCM activities in a Endevor/DB for IDMS Change Control Database (CCDB).
Migrate both dictionary and non-dictionary entities under the control of the CCDB, so that when you migrate an IDMS application from one dictionary to another, you can also migrate non-dictionary structures (for example, COBOL programs or CA Culprit for IDMS reports used with a CA ADS application).
Monitor dictionary and non-dictionary changes under one unified Change Control Identifier (CCID). You can assign a common set of CCIDs to Endevor SCM changes and dictionary changes and simultaneously monitor both sets of entities.
Perform an analysis of the impact of proposed changes.
The following functions are not performed by the Bridge:
  • Security measures including Preauthorization, Signout/Signin, Lock, and all security class data except NM-Mode and Migrate.
  • Source management for IDMS data dictionary entities.
When to Use the Bridge
Your organization benefits most from the Bridge product in the following circumstances:
  • You are currently using both Endevor SCM and Endevor/DB for IDMS separately, and want to tie together changes made to non-dictionary entities with changes made to dictionary entities.
  • You are currently using Endevor SCM and want to take advantage of Endevor/DB for IDMS release management support.
How the Bridge Executes
The Bridge program, C1DBBRDG, is an exit module that is executed in addition to other Endevor SCM user exits. As with other Endevor SCM user exits, the Bridge is transparent to the user.
The sequence of events at run time is as follows:
  1. The Endevor SCM user exit, if any, is executed.
  2. The Bridge program, C1DBBRDG, is executed and, depending on the exit, performs as follows:
    • At Exit 2, the Bridge validates actions, using the CCDB contents.
    • At Exit 3, the Bridge logs actions in the CCDB. (If you already have your own logging process set up at this exit, double logging occurs.)
    • At Exits 5 and 6 the Bridge performs general housekeeping activities.
The Bridge does not utilize Exits 1 and 4.
Commonly-Used Terms
The terms used throughout this document are part of standard Endevor/DB for IDMS terminology. A number of these terms are defined in the following table.
Archive Data Set
The data set that contains output from an Endevor SCM Archive and/or Transfer action. The archive data set can be any sequential file where RECFM = VB, LRECL has a minimum value of 800, and DSORG=PS.
The Change Control Database in Endevor/DB for IDMS that maintains a complete log of all changes made to a dictionary entity. The CCDB also stores information on users, migration activity, and security structures.
In the Bridge, the entity type assigned to an inventory element being monitored in a CCDB. See also the definition for Inventory Element.
The IDMS Integrated Data Dictionary (IDD) which contains data definitions, modules, documentation, and run time information for IDMS components.
In a multiple database/dictionary environment, a keyword in command syntax that identifies a particular group of databases. The group can include a CCDB, an IDD, and/or other databases. The keyword is followed by the name of the database/dictionary from which information is to be retrieved. The dictionary or database name that is specified refers to an entry in the IDMS Database Name Table (DB Table).
An object monitored by the Change Monitor in a CCDB. For example, an IDD object such as a dialog or a map, or a non-dictionary inventory element. An entity is identified by its name, version, and type.
A repository of definitions within Endevor SCM. An environment comprises a Master Control File and one or more libraries that contain the source for the entities. An environment is subdivided into two stages.
The information that uniquely identifies the entity being tracked, independent of its location. The complete identifier of an entity consists of its name, version number, and type.
IDMS Central Version (IDMS/CV)
In IDMS, a central copy of the database manager. This mode of operation allows multiple application programs to execute concurrently, sharing a single DBMS. The Bridge always runs under IDMS/CV.
Inventory Element
An object stored in an Endevor SCM environment (previously referred to as a C1-ELEMENT). An inventory element is identified by its system, subsystem, name, type, version, and level.
In a CCDB used under the Bridge, an inventory element is automatically logged with a type of C1-ELEMENT.
In Endevor SCM, a version qualifier that identifies different instances of an inventory element. For example, version 5 level 22 appears as 5.22. All levels of a given inventory element can coexist.
In Endevor SCM, a subdivision of the environment. An inventory element can be in Stage 1 or in Stage 2. Typically, you use Stage 1 as a transient holding area where you build the inventory elements before migrating them to Stage 2. Typically, you use Stage 2 for further testing before migrating the inventory elements to a production environment.
In Endevor SCM, a subgroup of a system; the secondary level within the environment hierarchy. Each inventory element is in a subsystem within a system.
In Endevor SCM, a logical group of inventory elements as they apply to major applications, departments, or work areas within an organization; the top level within the hierarchy of the environment. All inventory elements are assigned to a system.
The form of the element or entity. Types indicate how the element/entity is created (the source language used) and how it is manipulated. For example, COBOL, JCL, and copy books are
inventory elements
in Endevor SCM. Processes, dialogs, maps, and inventory elements are
types of entities
in Endevor/DB for IDMS.
A number that identifies an iteration of an inventory element in an Endevor SCM environment or a dictionary entity in the CCDB. Multiple versions of a single entity can coexist in a dictionary, whereas only a single version of an inventory element can exist at any one time in an Endevor SCM environment.