System Requirements

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.

Supported Platforms for Rational Web Platform

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.

Supported Platforms for ClearCase Mainframe Connectors Remote Build Feature

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

Supported File Systems

Table 5 lists the file systems that ClearCase supports.

Table 5 Supported File Systems by Platform
Platform Supported file systems
Windows NT FAT, NTFS, LANMAN, NFS1
Windows 2000 FAT, FAT32, NTFS, LANMAN
Windows XP FAT, FAT32, NTFS, LANMAN
1. See Table 6 for more information about NFS platforms

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:

• ClearCase File Server

• The third-party NFS client products listed in Table 6
• The third-party SMB server products listed in Table 7

Table 6 Supported NFS Client Products for Windows

Product Supported product releases
Hummingbird NFS Maestro 7.0.0.1, 7.1.0.6, 8.0.0.4
Shaffer Solutions Corporation DiskAccess 5.0 or 5.1
Table 7 Supported SMB Server Products for Windows NT
Product Platform Supported product
releases
LSI Logic Storage Systems TotalNET Solaris 2.6 or 5.4.1 patch 3,
Advanced Server (TAS) later 6.0, 6.1, 7.0
HP-UX 11.0 5.4.1 patch 3; 6.0, 6.1,
or later 7.0
AIX 4.3.2 and TAS 6.0, 7.0
above
 SAMBA (available from Solaris 8 or SAMBA 2.0.7, 2.2,
http://www.samba.org) later 2.2.6, 2.2.7a, 2.2.8
HP-UX 11.0 Samba 2.0.7, 2.2, 2.2.6,
or later 2.2.7a, 2.2.8
AIX 5.1 Samba 2.2, 2.2.6,
2.2.7a, 2.2.8
Linux RedHat Samba 2.2, 2.2.6,
7.2 2.2.7a, 2.2.8
For more information about using these products with ClearCase, see the Administrator’s
Guide for Rational ClearCase.

Disk Space Requirements

This section describes disk space requirements for running Rational ClearCase and
ClearCase MultiSite.

Disk Space Requirements for the Release Area

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.

Disk Space Requirements for Individual Hosts

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:

• Windows workstation or Windows server.

• A Web browser, either Netscape (version 7.0) or Internet Explorer (5.5, or 6.0).
Internet Explorer does not have to be the default browser, but is required for some
ClearCase features, including the ClearCase Explorer, the HTML DiffMerge tool,
and the ClearCase Administration Console. Rational recommends using Internet
Explorer 5.5 SP2 or later.
• IIS Web server software and the FrontPage Server Extensions (FPSE) are required
if acting as a server for the ClearCase integrations with Microsoft FrontPage 98,
Microsoft FrontPage 2000, or Visual InterDev.

Windows Server Software and ClearCase Servers

Windows workstations impose a limitation on concurrent access: a maximum of 10

systems can access a Windows system simultaneously by means of file system mounts or
UNC names. If you anticipate this level of use, install Windows server software on your
primary ClearCase servers.

Using ClearCase and Windows Domains

ClearCase is a distributed client/server application; many operations initiated on client

hosts are completed by server processes elsewhere in the network. Therefore, all
ClearCase hosts running Windows must belong to a Windows domain or an Active
Directory domain, except when running a single-host evaluation copy of ClearCase.
To use ClearCase from a supported Windows host, you must log on to a domain account
(not a local, per-system user account). For more information about Windows Domains,
see the Administrator’s Guide.

Operating System Vendor Web Site

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

There should be a "specialized" ClearCase Administrator account. This IS NOT a private
user's account, but is only used for the administration of the ClearCase system. Do not
put resumes, Swiss bank account numbers, or personal love letters on this system. All
non-ClearCase related information should be stored in a private system account.

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 Administrator's Directory Setup

Directory or File Description
Used by Kornshell as Login Resource File.
.profile This should be the standard .profile on your
system
The Env file. This is what the user execute
env to get a shell containing the ClearCase
environment
The Environment File. This is what
Kornshell sets the ENV variable too when
environment loaded. This file contains the aliases and
functions that make ClearCase a bit easier to
use.

Directory used to store all of the shell and

bin Perl scripts used in the ClearCase
environment
 bin/aix4 In a multiple machine type environment,
bin/hpux9 there may be some executables or even shell
scripts that are machine specific. These
bin/solaris directories contain the machine specific
binaries and shell scripts used in the
bin/sunOS
ClearCase environment.
clearstart root of the ClearStart data file tree
Directory that contains the customized magic
magic
files used on this site
Directory that contains the menus for the
menus/
utilmenu program
Directory that contains all the scripts and
triggers
programs used by triggers
Directory that contains the scripts that
triggers/mktrtype actually build the triggers in the various
VOBs

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.

The ClearCase Administrator's manual refers to several various types of ClearCase

servers, but in most small and medium sites, these are all usually on the same machine
which is sometimes genericly refered to as the ClearCase Server. The following are the
various types of servers that a ClearCase site might have. Most of these servers can be the
same system as the VOB Server with no degregation of service.

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.

The ClearCase Administrator's manual recommends to split your licenses between

systems and have multiple ClearCase License Servers, so if one License Server goes
down, the other licenses on the other License Server will still be available. However, if
you keep your licenses on the same system as you VOB server, this is unnecessary. If
your license server did happen to crash, then your VOBs are down anyway, and it
wouldn't matter if licenses were unavailable.

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.

ClearCase Release Server

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.

2. Full Copy Installation

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.

VOB Mounting Point

The VOBs are usually mounted directly off the root directory. The VOB mounting point
should be named after the project, and only those VOBs that are part of that project are
mounted there. The VOB mounting should reflect the setup of the software on the end
user's system.

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>

developerWorks > Rational >

How to set up ClearCase integration

for Rational Rose RealTime
Docume
Level: Introductory
Docum
Rational staff, Staff, IBM options
requirin
04 Dec 2003 JavaScr
are not
This example demonstrates procedures for setting up ClearCase for use with Rational Rose display
RealTime.

Overview New sit

Che
This example does not discuss the process of creating ClearCase VOBs or Views. Please see the new
ClearCase documentation concerning these activities. This example does not use the ClearCase and
Unified Change Management (UCM) feature. us w
thin
ClearCase uses a view model combined with a virtual file system that allows users to specify the Rate thi
lineup of file versions with which they want to work (a config spec controls the lineup used for a Hel
particular view). Rose RealTime then sees the files in the current view just as if they were stored this
on a regular (non-ClearCase) file system. Rose RealTime specifies the set of files that make up the
model, and ClearCase provides the versions of these files determined by the view's config spec. Thus the mo
saved to a view directory that is not view-private in order for the files to be added to source control.

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

Instructions for Windows clients

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.

Registering a new ClearCase element type

Element type setup: type manager

The following steps are required for making ClearCase clients aware of the new element type.

From a command prompt, run:

• rtperl %ROSERT_HOME%\bin\Win32\cc\mi_typeman.pl
-atriahome c:\Program Files\Rational\ClearCase

Turning on the "preserve case" option

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.)

ClearCase repository setup

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:

• cleartool mkeltype -supertype text_file -manager

petalrt_file_delta -c "RoseRT files" rosert_unit

Test the type manager

To determine if the rosert_unit element type has been successfully registered in the VOB, perform
command from a command prompt after changing to a directory contained in the VOB:

• cleartool lstype -long eltype:rosert_unit

A listing of the type details will verify that it is correctly registered.

Sample output

element type "rosert_unit"

07-Jul-00.12:09:10 by someone@machine
"RoseRT files"
owner: someone
group: groupid
scope: this VOB (ordinary type)
type manager: petalrt_file_delta
supertype: text_file
meta-type of element: file element

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.

Rose RealTime usage of the ClearCase setup

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

Instructions for UNIX clients

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:

Element type setup: type manager

ClearCase's cleartool command (often aliased as "ct") must be accessible from the shell prompt.

• Use the $ROSERT_HOME/bin/$ROSERT_HOST/cc/mi_typeman script to install the type manager i

ClearCase installation. To set up the extensions and tool mappings, the user executing the script must
the following directories in the ClearCase installation:

•
/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

A listing of the type details will verify that it is correctly registered.

Sample Output

element type "rosert_unit"

08-Nov-99.14:48:11 by Someone (someone@machine)
"RoseRT model unit, Version 1.0"
owner: someone
group: somegroup
scope: global
type manager: petalrt_file_delta
supertype: text_file
meta-type of element: file element

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.

Rose RealTime usage of the ClearCase setup

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 .").

The sequence of events will therefore be:

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.