Upgrading a Pre-Dimensions CM 12.1 Database Table

Before an upgraded pre-Dimensions CM 12.1 build system can be run in Dimensions CM 14.x you need to run the utility build_upgrade_nolists.exe. For details see the Installation Guide for Windows.

Submitting Parallel Builds through the Deployment Server Queue

In Dimensions CM releases prior to 12.1, build jobs ran on demand. If two builds were submitted at the same time, they ran in parallel with the customer responsible for avoiding clashes between the builds.

Dimensions 12.1 introduced the deployment server. Builds, like any other job that affected a deployment area, were queued, and ran in sequence one at a time.

In Dimensions 12.2.1 and later this strict sequential queuing has been relaxed to allow for parallel build jobs, while preserving the benefits of the deployment queue. This improves the throughput of build jobs in a highly stressed system. Build jobs take longer to run than deployment jobs therefore running multiple build jobs at the same time greatly increases the throughput of the deployment server queue.

Parallel builds affects build jobs submitted through the deployment server. These are the build jobs that you can see in the web client Deployment view tab. Currently the only type of build that is not launched in this way is a work area build, which does not use any deployment areas to supplement the search path. You can run these types of builds in parallel, as in previous releases.

CAUTION!  If you have independent teams coding changes to different parts of the system, and the changes overlap, parallel build jobs may cause confusion. The build system does not currently detect overlap between jobs automatically, and you will have to enforce this through working practices. If you are unsure you should disable parallel builds (see below).

Parallel Build Rules

The following rules describe how parallel builds work:

  1. Build jobs submitted from the same user client session are always run sequentially. This is essential for the reliable execution of batch scripts, which normally expect their commands to be run strictly sequentially. This rule applies to the client session, not the user ID. The same user can have multiple client sessions.

  2. Deployment jobs always run on their own. They do not run at the same time as other deployment or build jobs. This creates a quiet-point in the deployment log, which allows future rollbacks to be computed reliably.

  3. Build jobs can run in parallel with other build jobs, even in the same area subject to rule 1.

  4. Where there is an outstanding queue of work containing both build and deployment jobs that have not yet started, these jobs are automatically re-ordered to optimize the chances of the build jobs running in parallel. Reordering is designed to produce sequences of multiple build jobs and where possible allow them to run together, therefore improving the throughput of the system. For example:

If we represent a deployment job as "D", and a build job as "B", reordering is designed to take a queue of work such as "DB DB DB DB DB", and reorder it to produce "DDDDD BBBBB". This latter sequence allows the build jobs an opportunity to run together as all the deployment jobs have already been executed.

Deployment jobs and build jobs are never run out of sequence. Deploy1 is always run before Deploy2 and Build1 is always run before Build2.

Disabling Parallel Builds

Parallel builds are now the default. You can disable them by adding the following line to the %DM_ROOT%\dm.cfg file on the server:


If you set this flag the behavior will be the same as for Dimensions 12.1 and 12.2: all build and deployment jobs will be single thread, running one job at a time in the sequence in which they were submitted.