Defining Maps

This section contains the following topics:

Maps

Part of implementing CA Endevor SCM is to define the stages in the software lifecycles at your site, then organize these stages into environments. This section of this manual illustrates this process.

Applications in each lifecycle follow a unique route through the environment/stage locations that you have defined. You can set up as many routes as you need to accommodate different lifecycles at your site. These routes make up the map for your site.

CA Endevor SCM uses these routes to automatically add, display, retrieve, move, and generate inventory in a given lifecycle.

Consider the following examples:

Use environments DEV, QA, and PROD for production applications (Route 1), with an environment, QFIX, to handle emergency fixes to the applications (Route 2). Routes 1 and 2 might look like the following:
Use environments TSTDEMO and DEMO for the software used to demonstrate the production applications (Route 3). Route 3 might look like the following:

Note: When defining a map, the exit stage for an environment must always be Stage 2. The entry point into the next environment can be Stage 1 or Stage 2.

How to Define a Map

You define a map by:

Establishing the routes in the Defaults Table.
Using the System, Subsystem, and Processor Group Definition panels to identify inventory classifications at the successive locations in each route.

Establish Routes in the Defaults Table

To define a route, add the following statement to one or more C1DEFLTS TYPE=ENVRNMNT sections of the Defaults Table:

NEXTENV=(environment-name, stage-id)

The following information explains the variables in the previous statement:

environment-name: The name of the next environment in the route.
stage-id: The one-character identifier of the first stage in that environment that is on the route. The stage ID is optional, and if included, must be defined in the Defaults Table.

For example, to define Route 1 in the preceding section, add the following to the C1DEFLTS TYPE=ENVRNMNT section:

NEXTENV=QA: For environment DEV.
NEXTENV=(PROD,P): For environment QA.

Note: If you do not provide a stage ID, the specification defaults to Stage 1 of the next environment.

Mapping Inventory Classifications

You relate system, subsystem, and processor group names between stages in a route using the NEXT SYSTEM, NEXT SUBSYSTEM, and NEXT GROUP fields on the respective definition panels. You can change the following:

System and subsystem names when crossing environments.
Processor group names when crossing stages, environments, or both.

To simplify your routes, try to keep system, subsystem, type, and processor group names consistent across stages and environments.

Note: If you plan to change system or subsystem names across your map and use package component validation, see the Packages Guide for information about the potential impact of these name changes on package component validation functions.

To continue the Route 1 example, assume that there are the following inventory classifications:

System FINANCE in all environments.
Subsystem PO in all Finance systems.
Type COBOL in all stages in the map route within the Finance system.
Processor group BTCHCOB in all stages in the map route within type COBOL.

The following table indicates the values the administrator would enter in the NEXT SYSTEM, NEXT SUBSYSTEM, and NEXT GROUP fields:

	DEV UNIT	DEV INT	QA QA	QA HOLD	PROD FIX	PROD PROD
NEXT SYSTEM	FINANCE	FINANCE	FINANCE	FINANCE	NONE	NONE
NEXT SUBSYSTEM	PO	PO	PO	PO	NONE	NONE
NEXT GROUP	BTCHCOB	BTCHCOB	BTCHCOB	BTCHCOB	N/A	NONE

Note: Stage 1, Fix, of environment PROD, is not one of the locations in this map route, making a next group specification "not applicable".

Note: For more information, see Defining Inventory Structures and the Extended Processors Guide.

Design Strategies and Guidelines

This section describes the strategies and guidelines for defining routes.

Routes

The routes that you develop for your site can have a significant impact on your success in using CA Endevor SCM. When defining routes, consider the following information.

System and subsystem names can change only when going from one environment to another.
Processor group names can change when going between stages or between environments.

The examples that follow present two strategies for defining routes. Use these examples as a starting point when developing your own maps.

Stand-alone Routes

You can have more than one route in your map. For example, you might create one route for the production software lifecycle, and a second route for the lifecycle of the demonstration system for this production software.

This figure illustrates two routes in a map.

Each route is defined separately as follows:

Route 1 includes environments DEV, QA, and PROD.
Route 2 includes environments TSTDEMO and DEMO.

Converging Routes

Different routes can converge to include the same stages. For example, a site may have different environments for developing financial, manufacturing, and administrative applications, but have only one QA and one production environment. Routes for this site might look similar to the following illustration.

This figure illustrates how different routes can converge to include the same stages.

There are four routes at this site:

Route 1 includes environments DEVFIN, QA, and PROD.
Route 2 includes environments DEVMFG, QA, and PROD.
Route 3 includes environments DEVADMIN, QA, and PROD.
Route 4 includes environments QFIX and PROD.

Converging Systems within a Route

This example suggests a way to take advantage of map routes while minimizing the number of environments defined in the Defaults Table.

Consider an organization where Bill and Mary are developing a purchase order application. Quality assurance work on the completed PO application takes place in environment QA, and the production application is maintained in environment PROD.

To keep a single development environment (DEV), the administrator creates system BILL and system MARY in environment DEV, then defines subsystem PO to each of these systems. All four developers are working on COBOL programs, which have processor group COBOL in all stages of the route.

The administrator defines an environment map by adding the following lines:

NEXTENV=QA: Add this line to the C1DEFLTS TYPE=ENVRNMNT section for environment DEV.
NEXTENV=(PROD,P): Add this line to the C1DEFLTS TYPE=ENVRNMNT section for environment QA.

The administrator completes the NEXT SYSTEM, NEXT SUBSYTEM, and NEXT GROUP fields on the respective definition panels as follows:

	DEV UNIT	DEV INT	QA QA	QA HOLD	PROD FIX	PROD PROD
NEXT SYSTEM	FINANCE (on system BILL and system MARY definition panels)	FINANCE (on system BILL and system MARY definition panels)	FINANCE	FINANCE	NONE	NONE
NEXT SUBSYSTEM	PO	PO	PO	PO	NONE	NONE
NEXT GROUP	BTCHCOB	BTCHCOB	BTCHCOB	BTCHCOB	N/A	NONE

The following diagram represents the route:

This figure illustrates a route.

Implementation Checklist

Use the following steps for reference when defining routes.

Set up routes that reflect your software lifecycles. Draw a diagram of the routes first, using the previous examples as models.
Establish the routes in the Defaults Table.
Use the System, Subsystem, and Processor Group Definition panels to identify inventory classifications and processor groups at the successive locations in each route.
Note: You can also define your maps using batch SCL commands. For more information, see the SCL Reference Guide.
Run CONRPT07, System Definition Profile, to verify the routes are set correctly. In addition, run CONRPT07 whenever you change a route to verify that you have made the modifications correctly.
Note: For a sample of the CONRPT07, see the Reports Guide.