Three scripts to streamline and customize change management in Rational ClearCase and ClearQuest

Use these scripts for more flexible, efficient change management

This article describes three IBM® Rational® ClearCase® and IBM® Rational® ClearQuest® scripts for handling situations commonly faced by configuration managers and SCM administrators who deal with multiple teams. They often need to strike a balance between adding too many restrictions, yet maintaining a secure environment, and they sometimes need to cater to specific needs. These scripts can help in streamlining and customizing their procedures for delivering changes to development streams.


Vivek K Pandey (, Rational Change and Release Management Technical Consultant, IBM India Pvt Ltd.

author photoVivek Pandey is a certified Rational software specialist working in IBM Rational Lab services, in India. He has seven years of experience in software configuration management, standards and procedures development, software build and release management, change management training and configuration settings, and implementation in large projects in the banking, financial services, and telecom domains.

28 September 2010

Also available in Chinese

This article focuses on scripts for these purposes:

  • Allowing only few people to rename or move files between source-controlled folders, but still restricting everyone from deleting any file.
  • Allowing delivery of only one Unified Change Management (UCM) activity at a time from the development stream to the integration stream.
  • Implementing different actions for separate user databases that point to the same schema.

You can use these scripts in these situations:

  • The first script can be applied in any IBM® Rational® Clearcase environment, regardless of whether it is base or UCM setup.
  • The second script can be used only in UCM environments.
  • The third script (which is IBM® Rational® ClearQuest® database-related) should be used in cases where there is more than one user database pointing to the same schema but you still need to differ with some of the data, such as choice list, hook permission, record type visibility, and so on.

The sections that follow provide detailed descriptions of all three scripts.

Restrict rename and move operations

Maintaining configuration items within a secure repository is one of the main tasks of software configuration management. You should not allow deleting any artifact unless it is really necessary to do so.

It is a common practice to put a pre-operation trigger for the Rational ClearCase Rmname operation to ensure that no one is able to delete any artifact (un)intentionally. But when such a trigger is implemented, it restricts even the Rename and Move actions, because, internally, they invoke Rmname operations only.

Another view could be that configuration identification is an important aspect of configuration management. So, after the artifacts are identified and naming conventions are fixed, care should be taken that artifact names do not change often, and there should be control on rearrangement of files between folders. Otherwise, it could lead to confusion among team members about the exact path of the artifact.

Keeping this in mind, the following trigger script gives file rename and move permission to only specific users, and they are mentioned in the script. At the same time, file removal permission is still restricted for allusers.

Listing 1. script
#! /usr/bin/perl

$clearcase_user = $ENV{CLEARCASE_USER};


$match = Check_user();
if ($match == 1)
 # print "User-id matching. Has permission to go ahead with the trigger \n ";
 if ($pop ne "lnname")
  exit 1;
 else { exit 0; }
 # print "User does not have permission \n";
 exit 1;

sub Check_user
@exempted_users = (‘vivek.pandey','user.alpha','user.beta');
$result = 0;
foreach $i(@exempted_users)
  if ( $i eq $clearcase_user )
  { $result = 1;
    return $result;
return $result;

In this script, a Perl procedure, check_user(), matches the user ID with the existing list and returns the result if the user has permission to perform move or rename operations.

You need to use the ClearCase CLEARCASE_POP_KIND environment variable to decide whether a user has invoked a file-delete or move operation. If any user invokes a delete operation, the script exits without comparing the user IDs, thus restricting the delete operation.

The script in Listing 2 should be called while defining the trigger inside ClearCase VOB.

Listing 2. Script to call for defining the trigger
Cleartool mktrtype –element –all –preop rmname –execwin 
“ccperl” No_Rmname

While defining the triggers, we used the ccperl compiler, which is included with ClearCase, so that there is no need to install an appropriate Perl version separately.

Allow only one UCM activity in a single delivery from a development stream

In UCM, when you deliver some activity from development stream to integration stream, UCM creates one integration activity on the integration stream per delivery operation.

Which means, if you deliver more than 1 activity from development stream to integration stream in one go, there will still be single delivery activity created on the integration stream.

Assume a case where, there are multiple levels of check before delivering any work; hence there are multiple streams which are owned by different roles. Consider case in Figure 1.

Figure 1. Sample stream strategy in UCM
Diagram of the streams

In this situation, when a developer working on multiple tasks delivers all work spread across multiple UCM activities into the Defect Validation stream, UCM creates a single delivery activity in the target stream for any successful delivery.

Consider a case where the release lead okays only a subset of activities (two out of the four delivered) to be integrated into Integration stream. In that case, it is a challenge to pick only the activities that you want to deliver, because the activity present on the Defect Validation stream also contains work that you do not want.

As one of the solutions, there could be a process set where the user should deliver only one activity at a time. But there is no guarantee that all users will follow it 100% of time, especially when the release date is nearing and there is pressure to deliver lot of work.

To enforce such a process (deliver of only one activity at a time), you can use the trigger script,, shown in Listing 2..

Listing 3 shows the actual code.

Listing 3. Trigger script
#! /usr/bin/perl

my $from_stream = $ENV{CLEARCASE_SRC_STREAM};

# `clearprompt proceed -prompt $from_stream  -prefer_gui`;

if ($from_stream =~ /Development_Stream/)
   $delivered_acts = $ENV{CLEARCASE_DLVR_ACTS};
   @activities = split(/\s/,$delivered_acts);

   $no_of_activities = scalar(@activities);

   # `clearprompt proceed -prompt $no_of_activities  -prefer_gui`;

   if ($no_of_activities gt 1)
    `clearprompt proceed -prompt "You can Deliver only one activity at a time from 
Development Stream" -pefer_gui`;
    exit 1;

Here, you use the CLEARCASE_DLVR_ACTS environment variable to determine how many UCM activities have been selected to deliver from development stream. If no number of activities turns out to be greater than 1, then it exits and does not proceed with delivery.

The from_stream variable is used to determine the stream on which such restrictions should be applied.

This script should be called while defining the trigger in the UCM project VOB.

Listing 4. Defining the Trigger to allow deliver only one activity at a time
Cleartool mktrtype –ucm –preop deliver_start  -execwin 
“ccperl” Deliver_Only_One_Activity

Enforce separate implementation for clearquest user databases

Often, there are multiple user databases pointing to same ClearQuest schema. For example, one project development team might be catering to defects or change requests (CRs) coming in from different customers.

For maintaining customer privacy, it is often required that there are different user databases for different customers, but that they point to same ClearQuest schema. The defect or CR workflow is the same for all customers.

There might be cases where certain changes are required at the user database levels (adding a value to drop-down menu, different permission for different user databases, and such), yet they are to be implemented by keeping same schema. In such cases, take care that, while fulfilling one customer request, it does not interfere with another customer's requirements. With the same ClearQuest schema, any changes made to it will be reflected in all user databases.

To overcome this, you can use the following code snippet, where part of code is executed depending upon which of the user databases is affected.

Listing 5. Access control hook
$result = 0;
$database = $session->GetSessionDatabase();
my $userdb = $database->GetDatabaseName();
# $entity->SetFieldValue(userdb, $userdb);
if (($userdb eq "TEST1") || ($userdb eq "TEST2") || ($userdb eq "TEST3"))
	$result = 1;
     if (MemberOf("GroupA") == 1)
	     $result = 1;

The script above is an access control hook for the Submit action of the Review workflow. By using this hook, the following criteria have been fulfilled:

  • Any user should not be able to submit a Review record to the user databases, other than TEST1, TEST2, and TEST3 databases.
  • If a user belongs to ClearQuest GroupA, then only that person should be able to submit a record to any of the three databases.

MemberOf() is another record script that is used to check the group of the user who is trying to submit the record. However, it is not within the scope of this article to discuss that script.

Here, we are using the ClearQuest GetDatabaseName()API to determine the name of the user database in which the user is trying to submit the record.

This script can be further enhanced to implement other variations, such as different choice lists for different user databases, permissions according to the user databases, and so forth.

See the Resources section for information about ClearCase and ClearQuest.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

ArticleTitle=Three scripts to streamline and customize change management in Rational ClearCase and ClearQuest