Support for Wildcards in Build Configurations

When you add build sources from Dimensions CM you can add individual files or wildcard patterns representing multiple files, for example, COBOL(*). For details about using search paths with wildcards Search Paths.

The following options enhance the use of wildcards in build configurations:

• Item Formats: When you add a build source or pattern you can optionally specify an item format in the Build Type. This enables you to create multiple rules using the same pattern but have a unique item format or build type to keep each rule unique. For more details see Using Item Formats to Control Build Rules.

• Expanding Wildcards: When you add or modify a script for a target you can select the Expand Wildcards check box. This enables you to:

• Expand all the wildcard inputs and outputs for a transition at build time.

• Create an instance of the transition for each item that matches the wildcard.

Build Ordering

Build Ordering Prior to Dimensions CM 12.2.1

Prior to Dimensions CM 12.2.1 build ordering works as described below.

A build configuration contains a series of build rules that are executed to build your software. The order in which the rules are executed may be important, for example, you want component X to be built before component Y. Use the following methods to set up build ordering in a build configuration:

• Implicit Ordering

When one target rule (the intermediate target) is used as the input to another target rule (the final target) in a build configuration, the intermediate target must be built before the final target. For example:

LOAD(*)

 OBJ(*)

   COBOL(*)

In this example, all of the OBJ(*) build rules execute before the LOAD(*) build rules. This is called implicit ordering as it is determined automatically because of the nesting of build rules in the configuration.

• Explicit Ordering

Optionally, you can assign a numeric value to a target rule using the Build Order field. This value specifies the order in which the rule is built relative to the other rules in the same configuration. For example:

LOAD(*) - build order 2

 OBJ(*)

   COBOL(*)

LOAD(*) - build order 1

 OBJ(*)

   PLI(*)

In this example, all the PLI OBJs are created first, followed by the PLI LOADs, then the COBOL OBJs, and finally the COBOL LOADs. Notice how implicit ordering is done within the rules of explicit ordering.

A numeric build order can only be applied to final target rules in the configuration. If a build order is assigned to an intermediate target, the value cannot be higher than its parent, but it is ignored. Implicit and explicit ordering cannot conflict with each other.

A value of 0 in a build order indicates no order so the build rules will execute in a random order. By default, rules with no order build before any rules with an assigned order. However, you can change this by changing the value of force.unordered.transition.execute.later in web.xml to ’T’ (true). This causes items with no build order to run after those with an assigned order.

NOTE  web.xml is located in:

$DM_ROOT\Common Tools\tomcat\5.5\webapps\bws\WEB-INF

Build order values do not need to be sequential (1, 2, 3, 4…) and can have gaps between the values (5, 10, 15, 20…). You should leave gaps in build orders so that you can insert new build rules later without having to reorder the entire build configuration.

Build Ordering in Dimensions CM 12.2.1 (and later)

In Dimensions CM 12.2.1 and later the default behavior of build ordering has changed. The main benefits of the new behavior are:

• More efficient builds.

• Allows builds that include steps that fail to proceed much further.

Major and Minor Build Order Steps

Build steps can now optionally have major and minor orders. A major order is the number assigned to a group of build steps. Minor orders group the build steps in a major order. Both major and minor orders specify the sequence in which the build steps are processed.

For example, assume that you have the following build steps: S1, S2, S3, S4, S5, S6 and S7. Build steps S1, S2, and S3 are grouped together and have a major order of 1. Build steps S4, S5, S6, and S7 are grouped together and have a major order of 2. All build steps with a major order of 1 are processed before those with a major order of 2.

S1 has a minor order of 1, S2 has a minor order of 2, and S3 has minor order of 3. The build orders for this group are:

S1 (1,1)

S2 (1,2)

S3 (1,3)

Build step S1 is processed first followed by S2 and then S3.

S4 and S5 both have a minor order of 1, and S6 and S7 both have a minor order of 2. The build orders for this group are:

S4 (2,1)

S5 (2,1)

S6 (2,2)

S7 (2,2)

Build steps S4 and S5 are processed first followed by S6 and S7. Both S4 and S5, and S6 and S7, can be built in parallel.

Notes

• The major build order is set by the build administrator when adding targets to a build, for details see Creating Build Targets.

• Build ordering enables you to create complex configurations of build steps.

• The PBEM stops reading the Build Request Document when the build order changes. If there is a combination of major and minor orders the PBEM then consumes less resources and occupies less memory, which is useful for very large builds.

• If a build step fails you can execute subsequent build steps using the variable DM_ON_ERROR. Therefore, for large builds you can complete the build, and fix the failed steps later, without stopping the entire build process. This makes large build processes much more robust.

• Specifying a build order on other than the last of a chain of build rules has no effect and is ignored.

• Do not mix wildcard and explicit rules in a major build order. This combination is not supported by Serena.

Build Order Example

The minor build order is determined by the target type. The minor build order steps are arranged so that all entities that need to be built as in input to a type are built before any of the objects of that type. A type can be an extension of a target.

For example:

• Rule 1: LOAD(*) <<- OBJ(*) <<- ASM(*) [F1]

• Rule 2: LOAD(*) <<- ASM(*) [F2]

where:

• <<- this transition uses Dimensions CM wildcard expansion.

• [ ] is a build type that restricts the rule selection.

The following major build order steps are processed:

• ASM(S1) or ASM/S1.ASM format (=build type) = F1

• ASM(S2) or ASM/S2.ASM format (=build type) = F2

Using the above rules:

• All OBJ steps will precede any LOAD steps.

• In rule 1 the target types are OBJ and then LOAD.

• In rule 2 the target type is LOAD.

The minor build order steps are:

• Minor order 1:

construct OBJ(S1)

from ASM(S1)

• Minor order 2:

construct LOAD(S2)

from ASM(S2)

construct LOAD(S1)

from ASM(S1)

Notes

• Both steps in minor build order 2 may be run in parallel.

• Minor build order 2 will not start until all the steps in minor build order 1 are complete.

• This major build order will not be complete until all its minor build order steps are complete.

Build Order Variables

The system uses the following build ordering variables: