Professional Documents
Culture Documents
Use this section to determine compatibility of your platforms, file system, hardware,
software, and network before you install ClearCase.
See the Release Notes for the latest updates.
Supported Platforms
Version 2003.06.00 of ClearCase and MultiSite run on the platforms listed in Table 3.
Table 3 Supported Platforms for ClearCase and MultiSite
Hardware Operating system
platform
Intel x86 Windows NT 4.0 SP6a (but not 4.0 SP6) and SRP – Security roll
up Package, (Microsoft Knowledge Base Article - Q299444)
Windows 2000 SP2, SP3
Windows XP Professional SP11
Windows Server 20032
1Rational ClearCase 2003.06.00 clients support the latest Windows 2000, Windows NT,
and Windows XP Professional releases. Older releases of Windows, such as Windows 95,
Windows 98, Windows Me, and Windows NT 4.0 SP4, are no longer supported with this
release. We do not support Windows XP Home Edition. Customers who require support
for earlier releases of Windows must run an earlier version of ClearCase that supports
those releases
2The ClearCase Mainframe Connectors Remote Build Feature has not yet been tested
with Windows Server 2003.
The Rational Web Platform (RWP) provides support for Web interfaces to Rational
ClearCase and other Rational products. All supported ClearCase platforms support RWP.
RWP is installed by default on all servers.
The host must have adequate disk space available for the Web views that are created by
ClearCase Web interface users. Rational recommends 0.5 - 1MB of space per view.
If you plan to install the ClearCase Mainframe Connectors Remote Build Feature, see the
appropriate tables for platform requirements for the client (Table 3) and server (Table 4).
You must use TCP/IP to use this feature.
For more information, see the User's Guide for Rational ClearCase MainFrame
Connectors.
Table 4 Server Requirements for ClearCase Mainframe Connectors Remote Build
Feature
Hardware platform Operating system
IBM System/390 OS/390 2.10, including UNIX System Services (USS)
IBM zSeries OS/390 2.10, including USS
z/OS 1.3, including USS
Windows/UNIX Interoperation
This section provides information about ClearCase support for file access between
Windows and UNIX platforms, as it pertains to version 2003.06.00. As of this release,
ClearCase supports these Windows/UNIX interoperation products:
This section describes disk space requirements for running Rational ClearCase and
ClearCase MultiSite.
The file system of the networkwide release host must have sufficient disk space to hold
the release area. The minimum disk space required for each release area is 200 MB.
Table 8 shows the approximate disk space requirements for a new installation of
ClearCase. These figures are for ClearCase files and upgraded system files only. The
installation also needs 15 MB of temporary disk space.
Table 8 Disk Space Required for ClearCase Files and Upgraded System Files
ClearCase installation type Disk space
required
Windows NT, Windows XP, and Windows 2000 client or server 200 MB
using standard installation with dynamic views (5 MB additional to
support MVFS installation), local VOBs, and local views
Windows NT, Windows XP, and Windows 2000 client or server 240 MB
with all optional components
In addition, snapshot view directories need enough disk space to contain all files loaded
into the snapshot views and all view-private files added to the views. The amount of
space required depends on the number and size of the files in the views.
Any host that must contain VOB storage or view storage directories must have enough
disk space to contain the files and databases used for storage of these directories. The
amount of space required depends on the characteristics and use of the VOBs and views.
Software Requirements
ClearCase and MultiSite require additional software:
You can find up-to-date information about Microsoft Windows operating system issues at
the Microsoft Web site, http://www.microsoft.com.
Setting Up ClearCase
Hardware
The various ClearCase servers should be as powerful, and have as much memory as
possible. Since these are servers, there should be absolutely no one else logged into this
machine. In fact, some sites remove the NIS passwd table for these machines to prevent
other users from logging in. Although the ClearCase servers are quite busy, a typical user
might be tempted to use these machines simply because they do a "who" and don't see
anyone else using them. Removing the NIS passwd table prevents this temptation.
Most ClearCase sites have only a single ClearCase machine, but some of the larger sites
will have multiple VOB servers and view servers. The license server should also be
confined to these machines. These ClearCase machines should be considered the property
of the ClearCase Administrator, and the ClearCase Administrator should get root access
to these systems.
The ClearCase Administrator's $HOME directory should not be placed on the same area
or system as other user's $HOME directories. It should be placed upon one of the
ClearCase servers in a separate physical disk than where the VOBs or Views are stored.
Such a setup help keeps the ClearCase Administrator's files from being modified.
It is highly recommended that the ClearCase Administrator's shell be Kornshell, and that
the Kornshell be the default shell for all users. The ClearCase Administrator's account
name should be named after the project. This way, if there are more then one project, you
can setup a ClearCase Administrator for each project.
The setup of the ClearCase user's HOME directory should look something like this:
ClearCase Servers
ClearCase is a Client/Server style package. For example, all VOB information is kept on
a Server called a VOB Server. The user's ClearCase client system requests information
from the server which is sent to the user's machine.
One of the servers mentioned here, The View Server, is not mentioned in the ClearCase
manual. However, my personal experience has taught me that views should be distributed
from a server machines just as VOBs are.
VOB Servers
The machine that contains the VOB storage area is the VOB server. Theren maybe one or
more VOB servers depending upon the speed of the system, the number of users, and
most important of all, your budget. The ClearCase Administrator's Manual has some
important information on setting up the size and number of your VOBs, and the power of
your VOB server. See Chapter 6. Setting Up ClearCase VOBs.
One of the first concepts that most beginning ClearCase Administrators have to grasp is
that the VOBs are stored in one area, and the VOB tag is the mount point on the client
machine. Most ClearCase users will never realize that there is such a beast as the VOB
Server since the files stored in ClearCase appear magically on their system. As far as the
ClearCase user is concerned, the files stored in ClearCase are locataed on their machine.
View Servers
If you look in the ClearCase Administrator's manual, you will find no reference to a View
Server. Many sites simply allow users to setup ClearCase views under the user's $HOME
directory. These same sites will also spend many hours fixing views, reparing the
ClearCase registry, and many other view damaged related tasks because of the user's
tendency to think that if something is kept under their $HOME directory, they have a
constitutional right to futz with it. Although Triteal v. Erikson did not uphold any such
right, it is still hard to keep users from poking around with files stored under their
$HOME directory.Thus is born the concept of the View Server.
There are other reasons why storing all views in a single location is a good idea. In many
sites, the user's $HOME directory are not stored on the local machine, but instead on
another server. If this server becomes too busy, access to ClearCase could be slowed.
Also many sites have a policy that users are suppose to backup their own $HOME
directory which usually means it never does get backed up. Keeping all the views
together makes backups easier. It is also easier to rebuild the view registery if all the
views are in a single known location. In sites with a single ClearCase server, views may
simply be stored on the same system as VOBs.
Unfortunately, there is no way in ClearCase to set as a default where views are stored.
Instead, most sites rely on their own version of a mkview shell function or shell script
that calls the Cleartool mkview and forces the view directory to be stored on the View
Server. If a site uses ClearStart to start and define their view, making sure that all views
are stored on the View Server is easier.
License Server
The License Server is a very low CPU intensive server which is usually placed upon the
same machine that serves as the VOB server. Although the license process is a rather
small process, the process shouldn't be placed upon a system that is getting bogged down
by other processes. Plus, since the ClearCase Administrator has root access to the VOB
server, the ClearCase Administratorwill have access to the ClearCase License Database
file.
If your site has a dedicated license server machine that serves licenses for a variety of
software, then this system could serve as the License Server.
Registry Server
The Registry can be thought of as the "Table of Contents" to ClearCase's Vobs and Views.
The ClearCase VOB Registry links the VOB Tags (the mount points of the VOBs on the
ClearCase user's machine) to the directories where the VOBs are actually stored. The
ClearCase View Registry links the View Tags (the name of the view) to the directories
where the View is actually stored. It is recommended that a single Registry be used, and
the Registry server be placed on one of the standard ClearCase Server systems (usually
the VOB Server).
Sometimes, because of the way the local network itself is setup, it might be necessary to
have more than a single ClearCase Registry. Remember that the directory where the
VOBs and Views are stored must be able to be NFS mounted as read/writeable on all the
ClearCase client systems. In some networks, there may not be a standard description on
how the VOBs directories are to be mounted. For example, if the VOBs are kept on a
system called "vobserv", one client machine might insist that the directory where the
VOBs are stored should be mounted like this:
/net/vobserv/export/vobdir/demos/AdminVOB.vbs
While another client machine might insiste that the directory where the VOBs are stored
should be mounted like this:
/nfs/vobserv/export/vobdir/demos/AdminVOB.vbs
In this case, because one machine insists on using /nfs and another insists on using /net as
the NFS mount points, you will have to have two different ClearCase Registry Servers to
handle this problem. One for the systems that insist on the mount point of /nfs and the
other for the systems that insist on the mount point of /net.
The ClearCase Release Server is simply the machine were you loaded the ClearCase
CDRom. It is from this system that all other systems on your site will get ClearCase.
Normally, except for the installation of upgrades of ClearCase on the other systems, the
Release Server sees very little activity. However, if you are planning to do Link
installations, or Standard Installations, instead of Full Installations and Mounted
Installations, this server could see a lot of activity, which is why I normally recommend
against Link and Standard installations.
If you do plan on Link and Standard installaitons, then do not download the ClearCase
Release CDRom on any of your other ClearCase Servers. Some sites have a very
highspeed Application Server that might be a good candidate for the ClearCase Release
Server in this situation.
Installing ClearCase.
There are four methods of installing ClearCase on a user's machine (sometimes called the
Client machine). All users running ClearCase should install ClearCase on their local
machine. At a minimum, there are some adjustments made to the Unix kernel on the local
machine in order to run ClearCase. There are four methods for installing ClearCase on
users' machines
1. Standard Installation
Under the "Standard" installation the ClearCase command line tools are installed
on the local machine and so are most shared libraries. This takes about 20 to 30
megs of diskspace to install. Unfortunately, the GUI files and HyperHelp files are
accessed from the ClearCase Release Server. If you are like most sites, and install
the ClearCase Release on the same system that is serving as your VOB or View
server, you will find running the GUI will slow down you and the access to your
VOBs.
Under the "Full Copy" installation, all ClearCase files are stored on the user's
machine. Unfortunately, this might take anywhere between 90 to 110megs of
diskspace. However, it is probably the best way to install ClearCase, and if
diskspace is available, the way to install it. Otherwise, you might prefer the
"Mounted" method.
3. Linked Installation
Under this method, the ClearCase files (except for the files needed to modify the
Kernel and to start up ClearCase daemons) are linked back to the installation area
on the ClearCase Release Server. Although less than a single meg is needed for
this type of installation, if the release area is on the same system that is also
attempting to serve your VOBs, you will find running certain ClearCase tasks will
greatly slow down your network and your access to the VOBs
4. Mounted Installation
Under this method, the ClearCase files are completely installed on another system
via the Full Copy Installation method, then that area will be mounted on the client
machine being installed using the Mounted method. This method is prefered over
the Linked Installation method. If done correctly, you can configure the systems
to mount to other ClearCase areas on other client machines.
It is common to have the mounted release point to other application servers (where the
full copy of the client release has been installed). Since most application servers have
been designed for highspeed access, mounting ClearCase should not slow the user down.
Since the application server is also not the VOB server, access to the VOBs is not slowed
down either.
Sometimes little used ClearCase machines (like a machine sitting in a demo room) will
use the Mounted installation to another user's ClearCase system.
Basically, a Mounted Installation is very similar to size and operation of the Linked
installation, but a Mounted installation does not have to access the disk on the ClearCase
Release Server. Since almost all sites use the same system to store their VOBs as their
ClearCase release, this can be a very advantage.
The name of the VOB directory on the VOB server should match mounting point on the
user's machine with an additional extension of *.vbs on the end. You should also setup
one additional VOB to be used exclusively for the Administration VOB. This VOB
should be called "AdminVOB". The following is an example of how two projects would
be setup on the same VOB server. Note that they both have their own AdminVOB, and
each project also has its own ClearCase Administrative user:
Project DEMOS
VOB MOUNT POINT
VOB STORAGE AREA
(tag)
/net/vobstore/demos/src.vbs /demos/src
/net/vobstore/demos/bin.vbs /demos/bin
/net/vobstore/demos/lib.vbs /demos/lib
/net/vobstore/demos/include.vbs /demos/include
/net/vobstore/demos/AdminVOB.vbs /demos/AdminVOB
Name of ClearCase Administrator for project DEMOS: demos
Project SOMED
VOB MOUNT POINT
VOB STORAGE AREA
(tag)
/net/vobstore/somed/src.vbs /somed/src
/net/vobstore/somed/bin.vbs /somed/bin
/net/vobstore/somed/lib.vbs /somed/lib
/net/vobstore/somed/include.vbs /somed/include
/net/vobstore/somed/AdminVOB.vbs /somed/AdminVOB
Name of ClearCase Administrator for project SOMED:
somed/I>
It is important that each developer has his/her own work area. When working with ClearCase, a work area is
means that each developer should use a view that is dedicated for their sole usage and that should not be shar
developers.
ClearCase has a feature allowing a new element "type" to be defined that includes specifying a merge and dif
that should be used on files of the new type. Rose RealTime uses this to define an element type that applies t
RealTime files placed under source control. With this element type defined, all new Rose RealTime files that
a VOB are associated with that file type and will use Rose RealTime Model Integrator as their default merge
differencing tool.
Back to top
Registering a new ClearCase element type involves two steps. First, each ClearCase installation must be set u
manager" that will map file extensions to the new element type and indicates which executable to invoke for
operations. Second, the new element type must be registered in all VOB's in which it will be used.
The following steps are required for making ClearCase clients aware of the new element type.
• rtperl %ROSERT_HOME%\bin\Win32\cc\mi_typeman.pl
-atriahome c:\Program Files\Rational\ClearCase
Rose RealTime is case sensitive when looking for file names, so you must turn on the preserve case option fo
MVFS on WindowsNT:
• In the ClearCase HomeBase tool, select the 'MVFS' tab. (The ClearCase Control Panel tool can be sta
the Windows Control Panel or from the 'Administration' tab in the HomeBase tool)
o Make sure the 'Case Preserving' check box is checked.
o The MVFS service must be restarted for this change to take effect. (Note that this amounts to
MVFS system is actually a foreign file system.)
Each VOB must be set up to allow files of the new element type to be created. Follow the steps that apply to
below for each VOB that will be storing Rose RealTime files.
Open a command prompt window and change directory to a path within the VOB in which you wish to regis
create the element type, use the following command syntax:
Sample output
Note: Please see the online documentation on creating developer views to learn more about view-templates w
probably want to use in your configuration management scheme.
1. Use the ClearCase command line interface or gui to create a directory within the target ClearCase VO
directory an appropriate name for your model. Add this directory to source control and check it in.
2. Open the Rose RealTime toolset and create your new model or copy an existing model, if one exists,
directory. The possibility exists at this point to right click on the top model element in the Model View
select File>Control child units. This will allow the information stored in your model to be split up in
or configuration items when saved (do not save your model just yet).
3. Right click again on the model element in the Model View browser and open the model specifications
check box to enable source control and click the browse button under the Scripts directory text box w
become active. This should put you in the %ROSERT_HOME%/bin/win32/cmscripts directory (othe
to this directory). Next, select the cc directory and click OK. Optionally, check the "Add files to sourc
first saved" check box (the rest of this note assumes that this option was not selected).
4. This step continues with the assumption that the 'Add files to source control when first saved' option w
checked. The toolset will tell you that it is refreshing status from source control but unless you alread
versioned in ClearCase the status of every file in the model is "not under source control". Save the mo
an appropriate name in the directory you created in step 1. You will be prompted to accept the default
file names for each of your control units. You may say "Yes to all" to avoid being prompted multiple
file.
This will generate the directory structure and files identified at the beginning of Chapter 2 in the Team
Guide. For ClearCase, they become view private files at this point.
5. Right-click again on the model element in the Model View browser, select 'Source Control -> Add to
from the context menu. Answer "Yes" to the prompt about adding child units as well. You will be pro
list of control units that you can de-select if necessary. Do not de-select any of them unless you do no
be versioned. You can add control units to source control later if you do de-select items now.
6. Add an appropriate comment for the generation of the versioned items. You are also presented with th
keep the model elements checked out. This is not necessary.
7. It is recommended to check in your control units after adding them to source control from Step 5. Thi
pseudo-baseline of the original model. Now you can check out the particular control units you need. W
a change to an unit that is not checked out, you will be prompted by the toolset to check out the unit b
the change.
8. Optionally, outside the toolset, add the model's ".rtwks" file to ClearCase. This file will rarely need to
changes to it are brief and can be delivered quickly back to source control. Having this file in source c
ensures that all the developers are using the same CM settings and scripts. Updating the CM scripts is
easier.
Back to top
Registering a new ClearCase element type involves two steps. First, each ClearCase installation must be set u
manager" that will map file extensions to the new element type and indicates which executable to invoke for
operations. Second, the new element type must be registered in all VOB's in which it will be used. The setup
these steps is:
ClearCase's cleartool command (often aliased as "ct") must be accessible from the shell prompt.
•
/lib/mgrs
/config/ui/icons
/config/ui/bitmaps
/config/magic
• Use the following command line to set up the proper file extensions and tool invocations:
$ROSERT_HOME/bin/$ROSERT_HOST/cc/mi_typeman.sh install
-server
Register the rosert_unit element in each VOB
• Use the mi_typeman script to register the rosert_unit element type in each VOB using the following s
•
$ROSERT_HOME/bin/$ROSERT_HOST/cc/mi_typeman.sh
install
-eltype -vob <vob_path>
• (This note does not cover MultiSite replicated VOBs and administrative VOBs directly)
• Test the type manager To determine if the rosert_unit element type has been successfully registered in
perform the following command from a command prompt after changing to a directory contained in t
•
cleartool lstype -long eltype:rosert_unit
Sample Output
Note: Please see the online documentation on creating developer views to learn more about view-templates w
probably want to use in your configuration management scheme.
1. Use the ClearCase command line interface ct mkdir to create a directory within the target ClearCase V
this directory an appropriate name for your model. Before you can use this command, however, you w
check out the parent directory (i.e, "ct co -nc ."). Add this directory to source control and check it
to check the parent directory back in ( i.e., "ct ci -nc .").
ct co -nc .
ct mkdir -nc -ci <dirName>
ct ci -nc .
2. Open the Rose RealTime toolset and create your new model or copy an existing model, if one exists,
directory. The possibility exists at this point to right-click on the top "model" element in the Model V
and select File > Control child units. This will allow the information stored in your model to be split
files or control units when saved (do not save your model just yet).
3. Right click again on the model element in the Model View browser and open the model specifications
check box to enable source control and click the browse button under the Scripts directory text box, w
become active. This should put you in the $ROSERT_HOME/bin/<platform>/cmscripts directory (ot
navigate to this directory) and you should select the cc directory and click OK. Optionally, check Add
control when first saved (although the rest of this Tech Note assumes that it was not).
4. This step continues with the assumption that the 'Add files to source control when first saved' option w
checked. The toolset will tell you that it is refreshing status from source control but at this point the st
control unit in the model is currently "not under source control" unless you already had the model ver
ClearCase. Save the model, giving it an appropriate name in the directory you created in step 1. You w
prompted to accept the default directory and file names for each of your control units. You may say "Y
avoid being prompted multiple times.
This will generate the directory structure and files identified at the beginning of Chapter 2 in the Team
Guide. For ClearCase, they become view private files at this point.
5. Right click again on the model element in the Model View browser, select Source Control > Add to so
from the context menu. Answer "Yes" to the prompt about adding child units as well. You will be pro
list of control units, which you can de-select if necessary. Do not de-select any of them unless you do
to be versioned. You can add control units to source control later if you do de-select items now.
6. Add an appropriate comment for the generation of the versioned items. You are also presented with th
keep the model elements checked out. This is not necessary.
7. It is recommended that you check in your control units at this point as it establishes a pseudo-baseline
model. Now you can check out the particular control units you need. When you make a change to an
checked out you will be prompted by the toolset to check out the item before applying the change.
8. Optionally, outside the toolset, add the model ".rtwks" file to ClearCase. This file will rarely need to c
changes to it are brief and can be delivered quickly back to source control. Having this file under Cle
also ensures that all developers are using the same CM settings and scripts. Updating the CM scripts i
much easier.