SCLM ensures that all modules within the scope of a build are synchronized. If you build a source module, SCLM synchronizes the resulting object and listing with the source. If you build an architecture definition, SCLM synchronizes all members used as input to the builds and all members output from the builds. However, if there are object or load modules outside the scope of a particular build that are dependent on source modules within the scope of that build, those source, object, and load modules might no longer be synchronized.

In the following example, object modules OBJ1, OBJ2, and OBJ3 are produced by compiling source modules SOURCE1, SOURCE2, and SOURCE3, respectively. SOURCE2 might be the source module for an I/O routine many applications use. Load module LOAD1 is the result of linking OBJ1 and OBJ2, while LOAD2 results from the link-edit of OBJ2 and OBJ3. LOAD1 and LOAD2 might be two separate programs that run against the same kind of data and would therefore need to have a common I/O routine (SOURCE2). FLM01AP1 and FLM01AP2 are LEC architecture definitions that describe how to link-edit LOAD1 and LOAD2, respectively. Finally, TOPARCH is a high-level architecture definition that includes FLM01AP1 and FLM01AP2.

Figure 1. Example of Synchronization

In Figure 1, all of the modules shown in the diagram exist only in the production layer of your SCLM-controlled hierarchy and all source, object and load modules are synchronized. In other words, for each load module, the hierarchy contains the exact version of the object modules that were used to link-edit that load module. For each object module, the hierarchy contains the exact version of the source that was compiled to create that object module. You can always recreate exactly (except for time stamps) the object and load modules for the applications.

With this structure, you must pay close attention to which architecture definitions you use to build and promote development changes. The following scenario describes the INCORRECT use of architecture definitions, which leads to a loss of synchronization between source and load.

A user puts in a request for a change to LOAD1 and you decide that the way to implement that change is to modify SOURCE2. Because you are making a change to LOAD1, you also decide (in error as it will turn out) to use FLM01AP1 to drive your builds and promotes. When your changes are made and you are ready to build, you cause SCLM to rebuild OBJ2 (because SOURCE2 changed) and LOAD1 (because OBJ2 changed), by specifying FLM01AP1 on the Build panel. LOAD2 is not rebuilt, even though OBJ2 changed, because LOAD2 is outside of the scope of architecture definition FLM01AP1. Herein lies the problem. When you promote FLM01AP1, SCLM checks that everything that needs to be rebuilt (within the scope of FLM01AP1) has been rebuilt. Unfortunately, modules outside the scope of FLM01AP1 should be rebuilt as well.

When complete, all modules within the scope of FLM01AP1 are synchronized and recreatable. However, LOAD2 was outside the scope of the architecture definition you used and is not recreatable. Therefore LOAD2 is not synchronized with its source.

To avoid this problem, you must analyze the architecture of the applications in your SCLM-controlled project and choose an architecture definition with a scope that contains all modules that need to be rebuilt. The correct architecture definition would have been TOPARCH in the example because only TOPARCH has both LOAD1 and LOAD2 within its scope. These modules have to be relinked because of a change to SOURCE2.

It is strongly suggested that you have one high-level architecture definition with a scope that includes every module controlled by an SCLM project. You can use architecture definitions with much smaller scopes in your day-to-day development work. However, if you do that, you should also check the synchronization of all modules in the project by performing a build on the top high-level architecture definition as part of your testing.