Tutorials to get going for CCRC

The CCRC Plug-In includes extensive help for using CCRC. You can find it in Rational Software Architect Help if you have installed the CCRC Plug-in. Rational Software Architect provides cheat sheets to guide you through some of its application development processes.

Each cheat sheet is designed to help you complete a task, and it lists the steps required. As you complete each step, the cheat sheet starts the required tools for you. If a step in the process does not require a tool, you click a button in the cheat sheet to move on to the next step. Help for a task is available in a single click, which eliminates searches through lengthy documentation. For more information, search for "cheat sheets" in the help. You can create your own cheat sheets, which is a great way to include customer-specific processes and information for remote developers.

Common CCRC actions of a developer

New users might ask "What can I do with CCRC that I cannot do with the SCM Adapter Plug-In?" This is the answer:

• Install the CCRC Plug-In (one time)
• Update the latest patches and fixes for the plug-in, if any (depends on the release cycle)
• Create a CCRC view, and connect to it
• Load required projects and folders
• Import the required Team Project and project sets into the workspace
• Work in a perspective until you are ready to check in files to the repository
• Check out and check in files
• If working with UCM, perform rebase and deliver operations
• Update resources
• Update the load rules
• Search ClearCase repositories
• Show the history of elements
• Show the version tree of elements
• Remove ClearCase views
• Create baselines
• Recommend baselines

Common issues raised by users when using CCRC

Many users are not aware of all of the operations that are available in CCRC, and mistake the SCM menus for CCRC menus. Few users think CCRC can handle large amounts of data, which is possible but is not recommended. Also, CCRC adds new features from release to release. Because of these frequent updates, you might think that CCRC does not support the specific function that you want to use, but that might not be true. You might not have the latest version of CCRC, so be sure to check the latest version to understand whether it includes what you want. Below are some suggestions for avoiding common problems:

• Check for the latest CCRC update and fix
• Avoid performing large updates when time does not permit
• Disable the SCM Adapter when it is not in use
• In UCM
  • Perform update, rebase, and deliver operations frequently
  • Complete the rebase operations as often as possible
  • Complete the deliver operations
  • Use the Make/Recommend baseline operation in CCRC

Conclusion

Given the nature of CCRC, it changes the way you as developers see the ClearCase world through a Rational Software Architect window. It provides the following advantages:

• Ease of installation
• Lightweight code base
• Lower cost of ownership
• Automated update mechanism
• No server processes running on client hosts
• No dependency on the operating system login ID matching the ClearCase ID on the client
• Native look and feel – Windows and Linux look the same
• A new perspective dedicated inside Rational Software Architect.

It takes just few minutes for you to get up and running in CCRC. It provides much more flexibility to do work (even in other machines) with less effort. In addition, it lets you do all of your work inside the Rational Software Architect workspace instead of searching for non-Rational Software Architect tools (like ClearCase Project Explorer and so on). Best of all, it works through WAN.

CCRC Views

The CCRC Plug-In makes more ClearCase views available in the Rational Software Architect workspace. In the SCM Adapter Plug-In, none of these views exist in the Rational Software Architect workspace; instead it spawns a separate GUI outside of Rational Software Architect. Following is a partial list of the CCRC views that are now provided. Details are available in the Rational Software Architect Help.

ClearCase Navigator view

• Explores the contents of repositories and ClearCase views in your computer
• Displays a list of all ClearCase views on the local host, and allows you to explore their contents. It also allows you to explore the contents of remote ClearCase repositories (VOBs) and select resources to load into a local ClearCase view.

ClearCase Details view

• Provides detailed information about the ClearCase elements
• Use the ClearCase Details view in conjunction with the ClearCase Navigator view

ClearCase Metadata Explorer Navigator view

• Explores the metadata associated with base ClearCase and UCM VOBs.
• Viewing label types
• Viewing branch types
• Creating branch types
• Applying a label

ClearCase Metadata Explorer Details view

• Displays detailed information about ClearCase metadata.
• Use the ClearCase Metadata Explorer Details view in conjunction with the ClearCase Metadata Explorer Navigator

Other views

• ClearCase Deliver Results
• ClearCase History
• ClearCase Merge Manager
• ClearCase Rebase Results
• ClearCase Search Results
• ClearCase Version Tree
• ClearCase View Configuration

Best practices for GDD

User development environments are customizable, yet some standards and best practices help ensure smooth tool usage:

• Use Team Project Set to group the related projects
• Establish common preferences settings in your organization
• Search for checkout elements at the project level
• Avoid duplicate storage of components and elements
• Avoid sending huge files over the network
• Perform the administrative task of determining the optimum physical location for your servers. The physical location of the servers in a ClearCase environment is very important.
• Allow users flexibility, yet make the risks of deviating from standard practices known.
• Access the numerous configurations available via Preferences
  • See Window > Preferences
  • You can set "Ignored resources"

The most important items in this list are explained in the following sections.

Team Project Set

Team Project Set becomes important when your teams are doing parallel development in a producer-consumer environment, especially when an application needs multiple projects to function correctly. That forces everyone who wants to use this application to download all of the related projects to be successful. If there are fewer projects, making this mistake is less likely. But if an application includes dozens of projects, chances are good that someone on the team will forget to download some projects.

One way to ensure that all projects are handled as a single unit is to use Team Project Set. Using Team Project Set maintains an index file of the name and the physical location of the projects. When you import the index file, which is generally called a Team Project Set file, it imports all related projects into your workspace.

Preferences

Many CCRC preferences can influence the control behavior and appearance of the ClearCase operations. Each of them can be customized to meet business needs. Some preference settings, with the related available options, are shown below. To see all preference settings, click Window > Preferences

• After new resources are added to source control:
  • To have the ClearCase Remote Client add the resources to source control and then check them out, select Automatically checkout.
  • To keep the newly added resources checked in, select Do nothing.
• When checked-in files are edited or saved by an Eclipse editor, you can either:
  • Automatically checkout.
  • Prompt to checkout
• Hijack Options for Checkout:
  • To prevent the ClearCase Remote Client from hijacking the file when a checkout is not possible, select Do not hijack.
  • To allow hijacking only when you are disconnected from the ClearCase Web server, select Hijack only if disconnected.
  • To force a hijack even when a checkout is possible, select Always Hijack.

These preferences can be stored in a file (typically with the file extension .epf) inside the ClearCase repository for the team to share and reuse. Using common preferences helps you establish common ClearCase usage patterns, which can avoid unnecessary debates and discussions during collaborative development.

Search for Checked out elements

When you work in a J2EE project, many files are updated without your knowledge (as a developer), because the IDE follows the J2EE specification. Unfortunately, you cannot and will not know all of the files and directories that are affected when you create even a small Enterprise Java™Bean (EJB) component.

If your preference setting is Do Auto Check out, most of the J2EE metafiles are checked out without the knowledge of the developer. It will be a tough task for that developer to find all of the items for checkin. For example, a file like .../.settings/org.eclipse.wst.common.project.facet.core.xml must be checked in if there is an update to it. How do you know which elements you have checked out? In order to avoid potential pain and mistakes, be sure to run the ClearCase operation Search for all the Checked out elements at the Project level.

CCRC in GDD context & Getting Started with CCRC

The CCRC plug-in is well suited for GDD environments, given its ability to work in a WAN environment, as shown in Figure 1. It allows you to work in disconnected mode, although some operations require connection to a CCRC server. It can be a LAN and WAN client, and it supports users who work in the same office and in other environments. The Producer-Consumer rule can be enforced at the server level. Note that most of the GDD architecture guidelines are derived at the ClearCase Server level, not the CCRC level. The server infrastructure dictates client configuration possibilities.

What is special about CCRC in GDD? It uses specially-designed protocols to communicate efficiently over networks that have high latency:

• Includes many of the features provided by the native ClearCase client, and can run on a broad range of Windows- and UNIX computers, regardless of whether ClearCase is installed on them
• Permits access to the ClearCase repository from any machine, irrespective of your operating system user ID

Figure 1. CCRC: Breaking down the GDD walls

Getting started with CCRC

For an architect or developer, getting started with CCRC is easy; you can be up and running within few minutes without much effort. All you need to have is this information

• URL to CCRC Server (for example,http://server/ccrc)
• Your user name and password on the server
• If you are using UCM, the name of the project and the integration stream

For Version 2003.06.14 or later, download the CCRC client from your ClearCase server and install it. The installation will not work unless the IBM® Rational® Web Platform component is an installation choice on ClearCase server. By default, each CCRC server has an install site at http://server-name/ccrc/update. Ask your ClearCase server administrator for the details.

Simple installation and update

CCRC installation follows standard Eclipse Plug-In installation. Updating the fixes also follows the same Eclipse process, which uses public sites that contain the supported releases and fixes. CCRC also detects new updates on ibm.com and alerts users to update. Customers can establish a site policy to control the internal location of plug-in updates. This policy can help enforce a corporate standard for client version. For details, see http://www-1.ibm.com/support/docview.wss?uid=swg21196280. Client updates are not closely tied to server releases, which allows users to make more frequent client-side changes irrespective of the server.

Ensuring remote client performance

Performance is important when working in a GDD environment, and many factors affect it. To maximize your performance, keep these points in mind:

• All ClearCase operations are executed on the ClearCase server, so the proximity of traditional servers in a ClearCase environment is key
• CCRC does not eliminate performance issues at the server level, because it requires a predictable network connection. A large number of network hops, or hops that time out, affect client-to-server communications.
• CCRC is only a client. Avoid moving high volumes of data over the wire.

Enabling CCRC in Rational Software Architect

Disable the SCM Adapter option within Rational Software Architect.

1. To enable CCRC, click Preferences > General > Capabilities > Advanced.
2. By default, the ClearCase (CCRC) menu is available only in the ClearCase perspective. To make it available in the Customize perspective, click the Commands tab and then select ClearCase Main Menu.

Depending on how your preferences are set up, if the ClearCase SCM Adapter is active at the same time, you might see two ClearCase menus in your Rational Software Architect toolbar. One belongs to the SCM Adapter, and the other one to CCRC. Do not use the ClearCase menu that belongs to the SCM Adapter. If you do, you will not get the CCRC functionality.

Client and server compatibility

This section lists the compatible client and server versions. A V6.14.x client can access only a CCRC server V2003.06.04 (SR4) or later. A V7.0.0 or later client can access only a CCRC Server Version 7.0 or later. A single Rational Software Architect instance can have both a V6.14.x client and V7.0 client installed. However, only one can be activated at a time. There are few reasons why you might install more than one CCRC version:

• It helps facilitate migrations to new versions, or working on remote projects on other server instances.
• It helps when accessing different ClearCase servers that are at different release levels.

However, having more than one CCRC version is not recommended for most use cases.

For the latest support statement about which versions of desktop tools work with which versions of CCRC, go to http://www-1.ibm.com/support/docview.wss?uid=swg21253589

Differences between ClearCase native client and ClearCase Remote Client

It is helpful to understand how CCRC compares to the native ClearCase client, which is installed on the machine while using the SCM Adapter within Rational Software Architect.

Native ClearCase client

* Must be installed on each client host
* Has a LAN client that is powerful and rich with features
o Requires high speed connection
o Preferred client when high speed connection is available to servers
* Platform differences
o Microsoft® Windows®, Linux®, and UNIX® operating systems use different user interfaces
o Interoperability requires configuration: Samba or NFS Clients
* Supports dynamic and snapshot ClearCase views


CCRC

* Not installed on client host
* Powerful yet lightweight
o Communicates via HTTP to the server headings
o Uses Web views
* Small install footprint (Eclipse IDE plug-in is 32 MB)
* Platform support
o User interfaces are the same between Windows, Linux, and UNIX
o Samba and Interop packages are not needed
o Localized to nine spoken languages
* Flexible client support (plugs in to existing Eclipse IDEs based on V3.)
* True client
o No server processes locally (for example, Atria Location Broker Daemon or ALBD, and so on)
* Easy to install and update
o Follows standard Eclipse Plug-In installation and update process
o No dependency requiring the operating system login ID to match the ClearCase ID on the client
* Evolving and growing in each release

Simplify global development and delivery by using IBM Rational Software Architect and IBM ClearCase Remote Client

This article presents some of the tips, techniques, and best practices for integrating integrated development environment (IDE) and software configuration management (SCM) tools in a global development and delivery (GDD) environment.



Introduction

In a world of non-stop technology, teams are working across continents. Many businesses are now globally distributed, which presents the challenge of working with remote teams. These teams work in different time zones, speak different languages, follow different cultural practices, and work in completely different styles. Without general guidelines, controls, and checks and balances in the process, managing a project in a global development and delivery (GDD) environment is difficult.

This article presents some of the tips, techniques, and best practices for integrating integrated development environment (IDE) and software configuration management (SCM) tools in a GDD environment. These tools include IBM® Rational® Software Architect, IBM® Rational® Application Developer, and IBM® Rational® ClearCase® by means of the CCRC (ClearCase Remote Client) plug-in. This information was originally presented in the 2007 IBM Rational Software Development Conference, Orlando, Florida in June 2007, and to a customer in Chicago in November 2007. Now it is coming to you as a developerWorks article.

CCRC, Rational Software Architect, and ClearCase

The ClearCase Remote Client is a user interface that is powered by Eclipse and optimized for use by developers who connect to a ClearCase Web server over a wide area network.

The ClearCase Remote Client is available in two forms:

* The ClearCase Remote Client for Eclipse that integrates ClearCase with the software development environments provided by Rational Software Architect. When you install the ClearCase Remote Client for Eclipse into a Rational Software Architect environment, all ClearCase Remote Client viewers are available in the ClearCase perspective and can be added to other Rational Software Architect perspectives.
* The ClearCase Remote Client, a Standalone client that is designed for use outside of the Rational Software Architect IDE.

In this article, CCRC refers only to the CCRC for Eclipse client unless otherwise specified. Rational Software Architect includes Rational Application Developer and IBM® Rational® Software Modeler. Most CCRC functions are also applicable to these Eclipse-based products, because CCRC is built to work in Eclipse.

To best understand the ideas presented in this article, you are encouraged to review the Rational Software Architect and ClearCase documentation to learn about the product concepts and features. Also, note that "ClearCase views" are different from "Rational Software Architect views".

Rational Software Architect is part of the IBM® Rational® Software Delivery Platform, which offers these features:

* Support for model-driven development.
* Support for building Java™, Java™ 2 Platform, Enterprise Edition (J2EE™ Platform), and Web services applications.
* Includes tools and utilities for debugging, testing, and deployment.
* Integrates with IBM® WebSphere® Application Server Network Deployment.
* Enables direct deployment into WebSphere Application Server network.

ClearCase has two usage models for software configuration management:

* Unified Change Management (UCM)
* Base ClearCase


Methods of integrating Rational Software Architect with ClearCase

Rational Software Architect can integrate with ClearCase in two ways: by using the SCM Adapter (which is available with Rational Software Architect), or by adding the CCRC Plug-In. Each plug-in has its advantages. CCRC is the most recent; its simplicity and power to penetrate WAN environments is attractive to many developers. The key differences between these two plug-ins are as follows:

* SCM Adapter:
o Connects a native ClearCase client and Rational Software Architect
o Requires a LAN Connection
o Spawns ClearCase UI dialogs
o Requires traditional ClearCase client installation on the local machine
o Requires the MVFS (MultiVersion File System) if users need dynamic views
* CCRC :
o Embeds ClearCase into Rational Software Architect; does not require a native ClearCase client
o Supports latent network connections
o ClearCase client installation not required
o Separate ClearCase perspective and views inside Rational Software Architect
o Common look and feel across different operating systems

Tracing CCWeb client operations on Windows using Internet Explorer

To turn on Client side tracing:

1. Create a file named ccweb.options in your home directory.

Note: To determine your home directory open a command prompt (Start > Run type cmd) and type echo %HOME%.

2. Open the ccweb.options file with a text editor and add the following lines:

client_trace=true
client_trace_params=*:5
client_trace_output=console

3. Open Internet Explorer (IE) and select Tools > Sun Java™ Console

4. Repeat the steps in CCWeb to generate the errors in the logs.

5. In the Java Console, select the Copy button.

Paste the Java console data in a text file and send into ClearCase Support as an attachment.

Understanding about the ccweb.conf file

The ccweb.conf file is a configuration file that resides on the Rational Web Platform (RWP) server hosting CCWeb or CCRC clients.

Note: Prior to ClearCase 2003.06.00, an ordinary web server application (such as Apache) was used in place of RWP.

The configuration file can be found in its default location as follows:

Version	Path
Windows 4.2 and later	C:\Program Files\Rational\ClearCase\config\ccweb\ccweb.conf
UNIX/Linux 4.2 to 2002.05.00	/var/adm/atria/config/ccweb.conf
UNIX/Linux 2003.06.00 and later	/var/adm/rational/clearcase/config/ccweb/ccweb.conf or /opt/rational/clearcase/config/ccweb/ccweb.conf

As indicated in the header of ccweb.conf, the configuration file needs to be copied from it default location to the working directory on the RWP server.

The configuration file needs to be copied to the "config" working directory as follows:

Version	Path
Windows 4.2 and later	C:\Program Files\Rational\ClearCase\var\config\ccweb.conf
UNIX/Linux 4.2 to 2002.05.00	/var/adm/atria/config/ccweb.conf
UNIX/Linux 2003.06.00 and later	/var/adm/rational/clearcase/config/ccweb.conf or /opt/rational/clearcase/config/ccweb.conf

The configuration file makes changes to the RWP server for all clients to use and allows a ClearCase administrator to enforce certain policies when clients connect to the server.

A list of the options that can be configured on the RWP host can be found in the ccweb.conf file.

Simply remove the comment indicator (#) that is in front of the option you wish to enable and fill in the desired option as required.

Example:

The following option is found in the ccweb.conf file to change the temporary directory on the RWP host.

# -tmpdir pathname
#
# specifies an alternate location for temporary files. The default
# location is determined by various environment variables which could
# be set for the web server process, and may not be appropriate for
# user access.

To enable this option:

1. Delete the # in front of the option

-tmpdir pathname

Replace the pathname with an actual path on the RWP host

-tmpdir C:\temp

Accessing previous versions of an element from CCRC

Starting in CCRC version 7, you can access a previous version as detailed in technote 1209312.

In version 2003.06.14 through 2003.06.16, you can access a previous version of an element using a non-UCM view as detailed in these steps:

1. You need a non-UCM view created using a full version of ClearCase.

Note: If you only have access to CCRC, then you will need assistance from someone with access to a local install of ClearCase who can create the view with the syntax of the config spec you need.

2. The view's config spec must be set accordingly, to select the element version that you need to access:

· You can use a config spec like the following to get to the version of the element you need:

element * CHECKEDOUT
element
element * /main/LATEST

Example:

To get version /main/integration/10 of file test.c from the src directory if the VOB called \test_vob you could use the following:

element * CHECKEDOUT
element /vobs/test_vob/src/test.c /main/integration/10
element * /main/LATEST

When you create your CCRC view,

When you create your view from CCRC, click the drop-down arrow to select a config spec, and choose Fetch a list of view tags to browse...:

The window will reset, and when you select the drop-down again, it will list the views that are available for you to base your CCRC view off of, and Choose the view that has the config spec that selects the element version that you need to access:

Once the view is loaded, you can get the contents of the file, save them to your local machine.

Note: If necessary, you can copy and paste the changes you need from a previous version into the most recent version of the file, using the original CCRC view.

Uninstalling the ClearCase Remote Client from a Linux system

In a case where you wish to remove CCRC from a Linux host where it is no longer being used, the ClearCase Remote Client can be uninstalled by executing the uninstall binary following the steps below:

1. Login as root and run ls /opt/IBM/Rational/ClearCase/_uninst

In that directory you will find the following directories:

uninstall.bin
uninstall.dat
uninstall.jar

2. While logged in as root run /opt/IBM/Rational/ClearCase/_uninst/uninstall.bin and follow the steps as outlined below.

Note: If you are running a GUI desktop like KDE or Gnome, then the uninstaller will run and ask questions. If you are running the uninstall from a telnet session, you will need to add the switch -console to run in command line mode.

Example (telnet session):


[root@host1 _uninst]# ./uninstall.bin -console
InstallShield Wizard

Initializing InstallShield Wizard...

Searching for Java(tm) Virtual Machine...
........
Running InstallShield Wizard...

-------------------------------------------------------------------------
Welcome to the InstallShield Wizard for IBM Rational ClearCase Remote Client V7.0

The InstallShield Wizard will uninstall IBM Rational ClearCase Remote Client V7.0 from your computer.
To continue, choose Next.

IBM Rational ClearCase Remote Client V7.0


Press 1 for Next, 3 to Cancel or 4 to Redisplay [1]

-------------------------------------------------------------------------
IBM Rational ClearCase Remote Client V7.0 will be uninstalled from the
following location:

/opt/IBM/Rational/ClearCase

with the following features:

Rational ClearCase Remote Client

Press 1 for Next, 2 for Previous, 3 to Cancel or 4 to Redisplay [1]


Uninstalling IBM Rational ClearCase Remote Client V7.0...

-------------------------------------------------------------------------
The InstallShield Wizard has successfully uninstalled IBM Rational ClearCase Remote Client V7.0. Choose Next to continue the wizard.

Press 1 for Next, 2 for Previous, 3 to Cancel or 4 to Redisplay [1]

-------------------------------------------------------------------------
The wizard requires that you logout and log back in.

Press 3 to Finish or 4 to Redisplay [3]
WARNING: could not delete locked file /opt/IBM/Rational/ClearCase
WARNING: could not delete locked file /opt/IBM/Rational
WARNING: could not delete locked file /opt/IBM


Note: The above warnings can be safely ignored as you are sitting in a directory that it was trying to delete. The warnings can be avoided during the uninstall by calling the path from outside /opt/IBM/Rational/ClearCase/_uninst, then the first 2 directories can be deleted by the uninstall process.

Removing elements from CCRC

The Delete option in CCRC (highlighted in the screenshot below) performs the cleartool rmname operation under the covers which removes the reference to the selected file in the specific directory version which is subsequently created. The element and all it's history still exists in the VOB and can be referenced by viewing previous versions of the parent directory.

Solution

If your objective is to permanently remove the entire element and all of its history from the VOB, the cleartool rmelem command can be run from a full ClearCase client.

IMPORTANT: The rmelem command destroys information irretrievably. Use it carefully to avoid compromising your organization's ability to support old releases.

Writing triggers for the ClearCase Remote Client

BM® Rational® ClearCase® Remote Client (CCRC) supports interactive triggers that use clearprompt to interact with users. In a remote client-server environment like CCRC, there are considerations that trigger developers need to be aware of.

Solution

User Interaction

CCRC client now supports clearprompt interaction which:

· provides list, text, proceed, and yes_no dialogs.

· does not support File dialog because of ambiguities in client-side file selection versus server side utilization.

· times out after five minutes without user response.

Note: Under certain conditions, pre-op triggers will not work (for example, triggers that look into a file before the operation).

Since CCWeb (when being accessed by a browser) does not support clearprompt, trigger writers may need to adjust the behavior when writing triggers for all of the clients in the enterprise. The ATRIA_WEB_GUI environment variable can be used to distinguish between a CCWeb or CCRC user and a traditional “thick” client user. However, a ClearCase trigger cannot distinguish between a CCRC user and a CCWeb browser user. When a trigger fires that requires clearprompt for a CCWeb browser user, CCWeb should display an error message indicating that it doesn't support the clearprompt protocol and clearprompt will return an error code instead of a valid yes/no/abort/proceed response code.

Trigger Output

· If the CCRC operation fails, trigger output should appear in the client error message; for example, a pre-op checkin trigger that fails will cause the CCRC checkin operation to fail.

· If the CCRC operation does not fail, output is not shown (for example, because a post-checkout trigger failure won't stop checkout, output won’t be displayed). Trigger output may be present in internal status information returned from the host but it is not displayed to the user.

· On Windows, Perl scripts do not capture output from sub processes such as system calls (calls to clearprompt, for example) or secondary Perl scripts (nested triggers that call other triggers). So error messages can be lost before they get back to the client user.

Debugging suggestion: Since the client does not always see trigger output sent to stdout, the trigger developer can add a local function that prints debug output to a text file on the server for analysis.

Example:

sub debugPrint {

my ($m) = @_;
open (OUTFILE, ">>c:/temp/debugPrint.out");
print OUTFILE "$m\n";
close OUTFILE;
}

debugPrint(“Reached step one”);

Environment

CCRC runs as a client process that sends RPC commands to the CCRC server, where they are executed by separate CCRC server processes. These server processes run under Apache, so the environment variables (EVs) will likely be different from those seen in command shell windows during interactive development.

To display what the current system environment is for a CCRC server (this only displays RWP variables and basic web server or system environments):

· Pass http://hostname/ccrc/?cmd=dump in a browser and supply a username and password when prompted.

· To display a more detailed listing of a users credentials, use http://hostname/ccrc/?cmd=creds

The server config file (rwp.conf, ccrc.conf) can be modified to add environment variables using the SetEnv command. This is one way to set an EV that defines the machine OS, etc. There may also be other ways to get essential environment information using standard Perl packages like Config.pm instead of relying on locally defined EVs.

CCRC server processes are started as the "system" user and then impersonate the original CCRC client user. This means that the trigger can't assume EVs exist that define where the "user home" directory is (for example, "~" on UNIX or "Documents and Settings/" on Windows).

The primary group for a ClearCase Remote Client can be set under the workspace preferences (This is only applicable to Windows based CCRC Servers)

· Temporary files. The lack of reliance on a "home" or a persistent user temp directory can complicate relying on the EV's to determine where user-specific temporary files go and where data can be cached between trigger invocations. Using a more generic temp file directory and process-specific suffices (i.e. c:\temp\tempfile.2034) is one solution

· Paths to supporting executables can also be problematic if the path where the executables lives tends to rely on local user environment definitions (.cshrc and %USERHOME% etc)

ClearCase Operations

· The CLEARCASE_* EVs are defined because the trigger is a sub process under the server-side ClearCase operation , i.e. checkout.

· CLEARCASE_* pathname EVs (CLEARCASE_PN, CLEARCASE_XPN, etc) reference a temporary snapshot view on the server side (backing store) which is an unpopulated area where files appear temporarily during operations.

· The file may not exist in the server snapshot view when the trigger fires. A pre-checkin trigger will NOT see the file or the correct contents on the server side until AFTER the checkin has occurred. A post-checkin trigger will see the correct contents. The file will not necessarily stay around long after the operation so a later trigger for another file may find the earlier file no longer available.

The CLEARCASE_SERIES_* EV's are NOT currently supported. These EV's identify when a ClearCase operation is part of a "batch" of related operations, i.e. when checking out 10 files together. Currently interactive triggers can NOT determine when a series is in progress.

Creating config spec templates for remote users of ClearCase

If you wish to keep remote users in sync with config spec or load rule usage, here is a simple method that can be deployed to achieve this goal.

1. Create a view in the users' region with a view name to represent the "template".

For example, Project_XYZ_View_Template

2. Modify the config spec of this view and add the desired load rules and or configuration specifications as comments.

Note: A comment in a config spec is denoted by the # character preceding the line.

Example:

#Default config spec

element * CHECKEDOUT
element * /main/LATEST

Review the ClearCase Command Reference Guide on the topic of config_spec (cleartool man config_spec) for more information.


3. When the CCRC client creates a view, they can copy a config spec from another view in the same region.

Example:

Click the drop down menu to select the "template" view (in this example it is CompTeamCCRC)

Click the View config spec... to view the comments.

In this example you can see the instructions for the remote users.

To complete the example, you would Copy the load rule (highlight the load rule, right click and select Copy)

When you arrive to the load rule section of the view creation process, you could paste your item(s) in the load rule section.

Tracing CCRC client operations on Windows

How to turning on client side tracing for use in troubleshooting IBM® Rational® ClearCase® Remote Client (CCRC) issues on Microsoft® Windows®.

To enable tracing within CCRC:

1. Open a command prompt (Start > Run type cmd) and navigate to the CCRC installation directory:

(default) C:\Program Files\IBM\Rational\ClearCase\CCRC

2. Create a file named .options

Note: The file name must be created at the command line as Windows Explorer does not allow you to create files with a preceding period (dot).


Example:
C:\>cd C:\Program Files\IBM\Rational\ClearCase\CCRC

C:\Program Files\IBM\Rational\ClearCase\CCRC>notepad .options


The following window will appear - Click Yes

3. Type (or copy and paste) the following lines into the .options file:

com.ibm.rational.clearcase/client_trace=true
com.ibm.rational.clearcase/client_trace/output=file
com.ibm.rational.clearcase/client_trace/file_name=c:/ccrc_client.txt
com.ibm.rational.clearcase/client_trace/params=*:4
com.ibm.rational.clearcase/server_trace=true
com.ibm.rational.clearcase/server_trace/level=4
com.ibm.rational.clearcase/server_trace/subsys=CCRC

4. Start CCRC using the -debug switch.

Option 1:
Command line start: ccrc -debug

Example: C:\Program Files\IBM\Rational\ClearCase\CCRC>ccrc -debug


Option 2:
Modify the ClearCase Remote Client shortcut and add the -debug switch after the ccrc executable in the target window.

Note: The -debug switch must come first before any other switches.

Example:



Double click your new shortcut to start CCRC in debug mode.

5. A command window open and will display a message that the .options file was loaded successfully.

6. Use CCRC and reproduce the problem.

7. Locate the ccrc_client.txt file on the client located in the path specified on line 3 of the .options file (copied from step 3 above); by default at the root of the C drive.

8. Locate the trace log file on the Rational Web Platform (RWP) server:

C:\Program Files\Rational\ClearCase\var\log\trace\{USERNAME}\*.log

Understanding about Multiple ClearCase Region Support on CCRC 7.0.1 Servers

CCRC 7.0.1 servers now support multiple Rational ClearCase regions on a single server.

Users can be mapped to different regions depending on their username and primary group setting on the client side.

A Rational ClearCase administrator can specify or modify a mapping file (from username or group name to region) on the server.

Note: In previous releases, a Rational ClearCase Remote Client server could be set to support only a single Rational ClearCase region.

Below is an illustration of how the multiple region mapping feature in CCRC 7.0.1 can be leveraged




Default Region for CCRC Must be Specified

When a CCRC user does not have a valid mapping, and the Rational Web Platform (RWP) server does not have a default mapping, the CCRC user will receive the following error:

Unable to create a view at "C:\ccweb\user1\user1_view_a": error detected by ClearCase subsystem
ccweb: Error: Attempt to get host's network region failed: error detected by ClearCase subsystem.

(screenshot)


This error is an indication that the region is not set in the region map file as defined by the -user_region_mapfile specified by the RWP servers ccweb.conf file.

Example:

= { %DEFAULT% }