Distributed Rational Change (DCS) is the distributed change request tracking package. A change request is a problem or issue that is entered and tracked through to completion by using DCS.
DCS enhances change management functionality in the following ways.
- Change requests and tasks in any state are eligible for replication.
- A given change request or task can be modified or transitioned in only one database at a time within a DCM cluster. This operation is controlled by the modifiable_in attribute and security rules.
- Permission for the controlling database to modify or promote a specific change request or task can be handed over to another database in the DCM cluster.
- Change request and task resolvers can be chosen from a list that can include external database users listed in a Rational Change file.
- Transfer sets can define a change request scope that includes a change request query. The change request scope defines whether change requests are included. If they are, the change request scope also defines whether change requests include their associated tasks. If they do, the change request scope also defines the associated objects of each associated task.
- The change request scope and change request query of a transfer set can be defined using the GUI or CLI.
- Transfer sets can define whether the change request scope is cumulative or not. When disabled, the indirect change request members of the transfer set are precisely defined by the change request query and scope. Any members that no longer match the query are removed. When enabled, the scope query adds to the existing indirect change request members and all existing change request members are preserved. This option is typically enabled when change requests are replicated on a selective basis (using a specific change request query), especially when intermediate hub databases are used. This operation allows an object that was once replicated to a database to continue to be updated even though it is no longer found by the change request query defined for the transfer set.
- Only tasks that are assigned to a developer and modifiable in the current database can be used as the current task for the developer, or used to check out or check in objects. Possibly, such tasks were created and assigned in a different database and replicated to the current database.
- When a task is selected in a DCM-enabled database, it is displayed in the dbid#nnnn format; where dbid is the database ID, # is the DCM delimiter, and nnnn is the task number. This data appears in Rational Synergy task dialog boxes and certain fields in Rational Change.
- Parent/child and related change requests are supported.
You can configure DCS in the following ways.
- Transfer sets can exclude non-modifiable tasks. By default, tasks in any state are eligible to be included in a transfer package. If needed, the transfer set definition can exclude all incomplete tasks.
- Transfer sets can exclude imported objects. By default, transfer sets allow a database to generate a transfer package that includes objects that were received from other databases. This operation allows replication through a chain of such databases. If this option is disabled, the database in which the object was generated must always perform the replication to the receiving databases of the object.
- DCM model parameters allow DCS behavior to be adapted for complex DCS methodologies.