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:

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:

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:




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.

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




LOAD(*) - build order 1



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:

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.


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:


The following major build order steps are processed:

Using the above rules:

The minor build order steps are:

construct OBJ(S1)

from ASM(S1)

construct LOAD(S2)

from ASM(S2)

construct LOAD(S1)

from ASM(S1)


Build Order Variables

The system uses the following build ordering variables:


Description and Value


Specifies if the 12.2.1 (and later) build ordering functionality is enabled. If not, build processing uses the pre-12.2.1 functionality.

To globally enable or disable build ordering using the dm.cfg variable DM_BUILD_DMORDERING.

Values: YES and NO

Default: YES


Specifies that build orders with a value of zero are processed first.

Values: YES/NO

Default: YES (if DMORDERING is enabled)


Specifies if processing continues when errors are encountered in a group of build steps. If you specify PUSHON, processing continues.


Default: PUSHON


If DMORDERING is enabled you will see these variables in the BRD file.