Previous Topic: STRATEGY 3 - MINIMUM RELATIONSHIPSNext Topic: NDVRDSEL Command Syntax


Strategy Comparison

The following table identifies, by entity type, the selection of entities related to the promoting entity depending on the type of EXPAND IDD RELATIONSHIPS clause specified to NDVRDSEL (see syntax below).

It is important to note that the Promoting Entity is selected based on CCDB information (Change Log Entries and any selection criteria specified in the NDVRDSEL syntax), but during EXPAND IDD processing, related entities are selected based on their relationship to the promoting entity in the IDD.

Entities related to a selected entity, which should have been modified, but were not, may be listed on the EXCEPTION LISTING. For example, an APPLICATION selected for promotion is related to a RECORD, which is not selected, but the date last updated of the RECORD is more recent than the date last updated of the APPLICATION.

Promoting

Related

EXPAND IDD RELATIONSHIPS

Entity Type

Entity Type

CHANGES

HIERARCHY

MINIMUM

APPLICATION

LOAD MODULE

Always

Always

Always

 

RECORD

Modified

Always

Modified

DIALOG

LOAD MODULE

Always

Always

Always

 

MAP

Modified

Always

Modified

 

PROCESS

Modified

Always

Modified

 

RECORD

Modified

Always

Modified

 

SUBSCHEMA

Modified

Never

Never

ELEMENT

ELEMENT

Modified

Always

Modified

 

RECORD

Modified

Never

Never

FILE

FILE

Modified

Always

Modified

MAP

DIALOG

Modified

Always

Modified

 

LOAD MODULE

Always

Always

Always

 

MODULE

Modified

Always

Modified

 

RECORD

Modified

Always

Modified

 

TABLE

Modified

Always

Modified

MODULE

MAP

Modified

Always

Modified

 

MODULE

Modified

Always

Modified

 

PROGRAM

Always

Never

Never

PROCESS

DIALOG

Modified

Never

Never

 

PROCESS

Modified

Always

Modified

PROGRAM

MAP

Modified

Always

Modified

 

MODULE

Modified

Always

Modified

 

RECORD

Modified

Always

Modified

 

SUBSCHEMA

Modified

Never

Never

QFILE

QFILE

Modified

Always

Modified

RECORD

APPLICATION

Modified

Never

Never

 

DIALOG

Modified

Never

Never

 

ELEMENT

Modified

Always

Modified

 

MAP

Modified

Never

Never

 

PROGRAM

Modified

Never

Never

 

SCHEMA

Modified

Never

Never

 

SUBSCHEMA

Modified

Never

Never

SCHEMA

RECORD

Modified

Always

Modified

 

SUBSCHEMA

Modified

Always

Modified

SET

SCHEMA

Modified

Never

Never

SUBSCHEMA

DIALOG

Modified

Never

Never

 

LOAD MODULE

Always

Always

Always

 

PROGRAM

Modified

Never

Never

 

RECORD

Modified

Always

Modified

 

SCHEMA

Modified

Never

Never

TABLE

LOAD MODULE

Always

Always

Always

 

MAP

Modified

Always

Modified

Promoting Entity Type

Related Entity Type

DATE/TIME EXCEPTION LISTED

APPLICATION

LOAD MODULE

APPL > LOAD MODULE

 

RECORD

RECORD > APPLICATION

DIALOG

LOAD MODULE

 

 

MAP

MAP > DIALOG

 

PROCESS

PROCESS > DIALOG

 

RECORD

RECORD > DIALOG

 

SUBSCHEMA

SUBSCHEMA > DIALOG

ELEMENT

ELEMENT

 

 

RECORD

ELEMENT > Record

FILE

FILE

 

MAP

DIALOG

MAP > DIALOG

 

LOAD MODULE

MAP > LOAD MODULE

 

MODULE

MODULE > MAP

 

RECORD

RECORD > MAP

 

TABLE

TABLE > MAP

MODULE

MAP

MODULE > MAP

 

MODULE

 

 

PROGRAM

MODULE > PROGRAM

PROCESS

DIALOG

PROCESS > DIALOG

 

PROCESS

 

PROGRAM

MAP

MAP > PROGRAM

 

MODULE

MODULE > PROGRAM

 

RECORD

RECORD > PROGRAM

 

SUBSCHEMA

 

QFILE

QFILE

 

RECORD

APPLICATION

RECORD > APPLICATION

 

DIALOG

RECORD > DIALOG

 

ELEMENT

ELEMENT > RECORD

 

MAP

RECORD > MAP

 

PROGRAM

RECORD > PROGRAM

 

SCHEMA

RECORD > SCHEMA

 

SUBSCHEMA

RECORD > SUBSCHEMA

SCHEMA

RECORD

RECORD > SCHEMA

 

SUBSCHEMA

SCHEMA > SUBSCHEMA

SET

SCHEMA

SET > SCHEMA

SUBSCHEMA

DIALOG

SUBSCHEMA > DIALOG

 

LOAD MODULE

SSC > LOAD MODULE

 

PROGRAM

SUBSCHEMA > PROGRAM

 

RECORD

RECORD > SUBSCHEMA

 

SCHEMA

SCHEMA > SUBSCHEMA

TABLE

LOAD MODULE

TABLE > LOAD MODULE

 

MAP

TABLE > MAP

Generally for new development projects there is little difference between the three strategies, since all entities have been added and are selected in any case.

When maintenance promotions are undertaken, Strategy 1 will usually yield a much smaller and more efficient promotion list since only the changes will be promoted.

When maintenance promotions are undertaken in the situation where multiple maintenance teams were working on overlapping sets of entities, Strategy 3 may prevent the work of all the maintenance teams from being gathered together, and allow independent promotion. Note, however, that this may lead to inconsistencies in the target dictionary. In the case where the work of two teams is co-dependent, you must promote them together.