Rules using implicit states

Instead of specifying a particular state in the normal lifecycle, you can choose one the implicit states described in this topic.

Implicit states

You can choose an implicit state instead of the normal lifecycle state. Implicit states do not apply to build stages.

Other rules are required in such cases, as each such title implies its own order-of-preference grouping. For details about other rules, see Rule operation.

The following table describes implicit states:

Implicit state Grouping and order of preference  
*All revisions (*ALL)

All revisions of each relevant item of the type specified, regardless of their lifecycle status, are selected for inclusion in a baseline specified using this template. This is for use with Dimensions Archive, Retrieval, and Transfer facilities (ART).

If a baseline is made using a template which contains one or more rules with If a baseline is made using a template which contains one or more rules with *ALL, such a baseline cannot be used for configuration build or release control purposes., such a baseline cannot be used for configuration build or release control purposes.

  
*Latest edit revision (*LATEST)

There is just one group, consisting of all revisions which are at any of the normal lifecycle states.

It is equivalent to choosing the first normal lifecycle state specifically, with a LFS rule.
*Latest edit revision at final state in lifecycle (*FINAL)

There is just one group, consisting of revisions at the final normal lifecycle state only.

It is equivalent to choosing that state specifically, with an EQS rule.
*Latest edited revision at the most progressed state (*HIGHEST) The order of preference of the groups is:

  1. The group of revisions (if any) at the final normal lifecycle state.

  2. The group of revisions at the next-to-final state.

  3. And so on downwards to the group at the first normal lifecycle state.

It is equivalent to choosing that first state specifically, with a MPS rule.

This implicit state is principally of value at an early stage in the development of a product, as it ensures that every relevant existing item (of the type that the rule is concerned with) gets selected at the latest revision of its most progressed status.
*Revision built from selected inputs (*BUILT)

The selection procedure here is different from that for other implicit states.

Regardless of the order in which they were specified, rules with implicit states *BUILT and *MADE OF are interpreted after all other rules have been used to select item revisions of other types.

All relevant items of the types specified in *BUILT rules are reviewed for potential inclusion in the baseline, and each relevant item is inspected individually. The lifecycle status of the relevant item's revisions is not significant in this case, but each of the revisions is considered in turn, to see if one can be found which has been built, using as inputs some of the item revisions already included in the baseline.

For such a revision to qualify, it must have been the output of a Dimensions build process, and all the inputs used in that process must be found, either already included in the baseline (as a result of processing the template rules of other types (rules other than *BUILT), or included in the baseline as a result of earlier processing by this *BUILT procedure.

Note: It does not matter in which order *BUILT rules are specified because this *BUILT processing is reiterative: the whole cycle is repeated as often as necessary on all the relevant items of types in *BUILT rules, until all possible orders and combinations have been dealt with.

If such a revision can be found to qualify, then this revision is also included in the baseline, and the item is considered to have been successfully selected.

If each of the item's revisions has been considered, and none has been found to meet these criteria (and further iterations of the entire cycle could not improve on this), a warning message is issued to say that this item has not been included in the baseline. The inspection process starts over again on the revisions of the next relevant item.
*Revision that makes selected outputs (*MADE OF)

This selection procedure uses an inverse criterion to that used for *BUILT.

In *MADE OF rules also, the lifecycle status of relevant item revisions of the types specified is not significant in selecting them for inclusion in the baseline.

In *MADE OF rules the selection is made by examining the made-of lists of built item revisions which are already in the baseline or have been included in it as a result of previous iterations of this *MADE OF processing.

Wherever such a made-of list contains any item revision which is of the types specified in *MADE OF rules, as well as being a relevant item (within the scope of the baseline), then that item revision is also included in the baseline, provided that no other made-of list so examined contains a  different revision of the same item. If such a conflict of revisions arises, no revision of that item is included in the baseline, and an error message is issued to explain this.

For details about the *BUILT and *MADE OF rules, see Use *BUILT and *MADE OF implicit states.

Back to top

Default rule and other implicit state uses

The default rule (item type *) is applied to all item types not specified in other rules.

The default types may be associated with several different item lifecycles. Therefore no specific lifecycle state may be used in the default rule. Instead, one of the implicit states must be chosen. Therein lies the value of such titles as *FINAL, *LATEST and *HIGHEST, as they can be reinterpreted according to the different lifecycles associated with the types of item selected by the default rule.

The default rule is a short alternative to specifying a separate rule (with the same implicit state in each) for every item type used by all the relevant items, except for the item types that have rules to themselves.

The implicit states can be useful in other rules.

Example: If a template is to select items of several different types, and for each of them to pick the latest revision at the final normal lifecycle state, you can choose *FINAL for the rule for each of these item types. It may be simpler than looking up and selecting the name of the actual final normal state in each case. The template would function equally effectively, specified either way.

A further advantage of implicit states can be in defining general-purpose templates, for use by several different products.

Example: Several products may have items of type XYZ, but in each product a different lifecycle is specified for that item type. Any of these products could use a template consisting of the single rule XYZ *LATEST to create a baseline that included the latest revision (at any normal lifecycle state) of each relevant item of type XYZ.

Back to top

Use *BUILT and *MADE OF implicit states

This section provides examples of how the *BUILT and *MADE OF implicit states can be used.

A typical build configuration includes:

  • A compiler build tool which produces one item of type OBJECT from one input of type SOURCE.

  • A linker build tool which produces one output item of type EXE from several inputs of type OBJECT.

Typically, there are other inputs in addition to these. But by considering this simple example of a configuration with three item types, it is apparent how *BUILT and *MADE OF can be used in any configuration.

EXE *BUILT
OBJECT *BUILT
SOURCE *MADE OF

The order in which template rules are specified in this example doesn't affect the content of a baseline.

This template has the following effect:

  1. Because *BUILT processing comes at the end, to include in the baseline SOURCE item revisions at the *FINAL (i.e. final normal) state.

  2. To include those OBJECT item revisions which were built (compiled) from the SOURCE revisions already included.

  3. To include any EXE item revisions built (linked) from some combination of these included OBJECT revisions.

There must be a specified rule, or the default rule, to cover each stage in the build process. If the rule for OBJECT had been omitted, then the rule for EXE could not have included anything because none of the build inputs for any EXE item would be present.

EXE *HIGHEST
OBJECT *MADE OF
SOURCE *MADE OF

The order in which template rules are specified in this example doesn't affect the content of a baseline.

This template has the following effect:

  1. Because *MADE OF processing comes at the end, to include in the baseline all the EXE items, choosing the revisions at the *HIGHEST state, for example, the best revision available for each EXE item.

  2. To include those revisions of OBJECT items which were used to build the revision of each EXE item already included, unless it is found that two or more different revisions of the same OBJECT item were used in building those EXE items (the EXE rule would have to have included at least two different items for such a conflict to possibly arise). If such a conflict is found, it is flagged and reported, and no revision of that OBJECT item is included.

  3. To include the SOURCE item revisions which were used to build each OBJECT item revision already included (and therefore not flagged) – which, provided that there is a one-to-one correspondence between SOURCE and OBJECT items, does not result in any further conflicts being found.

There must be a specified rule (or the default rule) to cover each stage in the build process. If the rule for OBJECT had been omitted, then the rule for SOURCE could not have included anything because the SOURCE items do not themselves belong to the made-of list of any EXE item. Although an EXE item is built ultimately from SOURCE items, this requires made-of lists to be used in combination.

OBJECT *LATEST
SOURCE *MADE OF
ENV*MADE OF

ENV items are environment items, some of which may be used in the build compilations of several different OBJECT items. Different revisions of one ENV item might have been used in the compilations which produced the OBJECT items already included.

For example:

EXE *BUILT
OBJECT *LATEST
SOURCE *Revision that makes selected outputs

Other rules in this template must include items which are in-between in the build process. This means that the rules for *BUILT inclusion and those for *MADE OF inclusion never conflict with each other. In this example OBJECT items have been included first, followed by both the EXE revisions built from them and the SOURCE revisions used to build them.

For example:

OBJECT *BUILT
SOURCE *MADE OF

Such a template would include nothing because there is nothing selected to start off with. Neither the *BUILT nor the *MADE OF processing could possibly find anything to qualify for inclusion.

Considerations:

  • *MADE OF rules do not guarantee that the baseline includes the entire contents of any made-of list. If a complete made-of list is to be assured of being included, then either the template should be designed to use *BUILT; or else the *MADE OF rules must be sufficiently all-embracing to cover the made-of list. For example:

    EXE *HIGHEST
    * *MADE OF

    This could be used to include all the made-of lists for the included EXE items, but only if the baseline scope is large enough to include every configuration part which was specified or implied in each of the build processes.

  • *BUILT and *MADE OF rules are incompatible with *ALL rules. Neither *BUILT nor *MADE OF may be used in any template which contains one or more *ALL rules.

Back to top

See also: