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 platform

Operating system

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 Advanced Server (TAS)

Solaris 2.6 or later

5.4.1 patch 3, 6.0, 6.1, 7.0

HP-UX 11.0 or later

5.4.1 patch 3; 6.0, 6.1, 7.0

AIX 4.3.2 and TAS 6.0, 7.0

above

SAMBA (available from http://www.samba.org)

Solaris 8 or later

SAMBA 2.0.7, 2.2, 2.2.6, 2.2.7a, 2.2.8

  HP-UX 11.0 or later

Samba 2.0.7, 2.2, 2.2.6, 2.2.7a, 2.2.8

  AIX 5.1 Samba 2.2, 2.2.6, 2.2.7a, 2.2.8

  Linux RedHat 7.2

Samba 2.2, 2.2.6, 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 using standard installation with dynamic views (5 MB additional to support MVFS installation), local VOBs, and local views

200 MB

Windows NT, Windows XP, and Windows 2000 client or server with all optional components

240 MB

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

.profileUsed by Kornshell as Login Resource File. This should be the standard .profile on your system

envThe Env file. This is what the user execute to get a shell containing the ClearCase environment

environment

The Environment File. This is what Kornshell sets the ENV variable too when loaded. This file contains the aliases and functions that make ClearCase a bit easier to use.

binDirectory used to store all of the shell and Perl scripts used in the ClearCase environment

bin/aix4 In a multiple machine type environment, there may be some executables or even shell scripts that are machine specific. These directories contain the machine specific binaries and shell scripts used in the ClearCase environment.

bin/hpux9

bin/solaris

bin/sunOS

clearstart root of the ClearStart data file tree

magicDirectory that contains the customized magic files used on this site

menus/Directory that contains the menus for the utilmenu program

triggersDirectory that contains all the scripts and programs used by triggers

triggers/mktrtypeDirectory that contains the scripts that 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 STORAGE AREAVOB MOUNT POINT

(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 STORAGE AREAVOB MOUNT POINT

(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

Level: Introductory

Rational staff, Staff, IBM

04 Dec 2003

This example demonstrates procedures for setting up ClearCase for use with Rational Rose RealTime.

Overview

This example does not discuss the process of creating ClearCase VOBs or Views. Please see the ClearCase documentation concerning these activities. This example does not use the ClearCase Unified Change Management (UCM) feature.

ClearCase uses a view model combined with a virtual file system that allows users to specify the lineup of file versions with which they want to work (a config spec controls the lineup used for a particular view). Rose RealTime then sees the files in the current view just as if they were stored 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 model must be 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 a view. This means that each developer should use a view that is dedicated for their sole usage and that should not be shared with other developers.

ClearCase has a feature allowing a new element "type" to be defined that includes specifying a merge and differencing tool that should be used on files of the new type. Rose RealTime uses this to define an element type that applies to all Rose RealTime files placed under source control. With this element type defined, all new Rose RealTime files that are placed into a VOB are associated with that file type and will use Rose RealTime Model Integrator as their default merge and differencing tool.

Back to top

Document options

Document options requiring JavaScript are not displayed

Print this page

E-mail this page

New site feature

Check out our new article design and features. Tell us what you think.

Rate this page

Help us improve this content

Instructions for Windows clients

Registering a new ClearCase element type involves two steps. First, each ClearCase installation must be set up with a "type manager" that will map file extensions to the new element type and indicates which executable to invoke for merge and diff 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 for the ClearCase MVFS on WindowsNT:

In the ClearCase HomeBase tool, select the 'MVFS' tab. (The ClearCase Control Panel tool can be started from either 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 a reboot as the 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 your platform 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 register the type. To 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 the following 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 which you will 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 VOB and give this 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, to this new directory. The possibility exists at this point to right click on the top model element in the Model View browser and select File>Control child units.  This will allow the information stored in your model to be split up into separate files 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. Click on the check box to enable source control and click the browse button under the Scripts directory text box which has become active. This should put you in the %ROSERT_HOME%/bin/win32/cmscripts directory (otherwise navigate to this directory). Next, select the cc directory and click OK. Optionally, check the "Add files to source control when 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 was not checked. The toolset will tell you that it is refreshing

status from source control but unless you already had the model versioned in ClearCase the status of every file in the model is "not under source control". Save the model, giving it an appropriate name in the directory you created in step 1. You will be prompted to accept the default directory and file names for each of your control units. You may say "Yes to all" to avoid being prompted multiple times for each file.

This will generate the directory structure and files identified at the beginning of Chapter 2 in the Team Development 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 source control' from the context menu. Answer "Yes" to the prompt about adding child units as well. You will be prompted with a list of control units that you can de-select if necessary. Do not de-select any of them unless you do not want them 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 the option to 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. This establishes a pseudo-baseline of the original model. Now you can check out the particular control units you need. When you make a change to an unit that is not checked out, you will be prompted by the toolset to check out the unit before applying the change.

8. Optionally, outside the toolset, add the model's ".rtwks" file to ClearCase. This file will rarely need to change and changes to it are brief and can be delivered quickly back to source control. Having this file in source control also ensures that all the developers are using the same CM settings and scripts. Updating the CM scripts is therefore much easier.

Back to top

Instructions for UNIX clients

Registering a new ClearCase element type involves two steps. First, each ClearCase installation must be set up with a "type manager" that will map file extensions to the new element type and indicates which executable to invoke for merge and diff operations. Second, the new element type must be registered in all VOB's in which it will be used. The setup required for 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 in each ClearCase installation. To set up the extensions and tool mappings, the user executing the script must have access to 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 syntax:

$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 the VOB, perform the following 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"

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 which you will 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 VOB and give this directory an appropriate name for your model. Before you can use this command, however, you will first have to check out the parent directory (i.e, "ct co -nc ."). Add this directory to source control and check it in. Don't forget 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, to this new directory. The possibility exists at this point to right-click on the top "model" element in the Model View browser and select File > Control child units.  This will allow the information stored in your model to be split up into separate 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. Click on the check box to enable source control and click the browse button under the Scripts directory text box, which has become active. This should put you in the $ROSERT_HOME/bin/<platform>/cmscripts directory (otherwise navigate to this directory) and you should select the cc directory and click OK. Optionally, check Add files to source 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 was not checked. The toolset will tell you that it is refreshing status from source control but at this point the status for every control unit in the

model is currently "not under source control" unless you already had the model versioned in ClearCase. Save the model, giving it an appropriate name in the directory you created in step 1. You will be prompted to accept the default directory and file names for each of your control units. You may say "Yes to all" to avoid being prompted multiple times.

This will generate the directory structure and files identified at the beginning of Chapter 2 in the Team Development 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 source control from the context menu. Answer "Yes" to the prompt about adding child units as well. You will be prompted with a list of control units, which you can de-select if necessary. Do not de-select any of them unless you do not want them 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 the option to 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 of the original model. Now you can check out the particular control units you need. When you make a change to an item that is not 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 change and changes to it are brief and can be delivered quickly back to source control. Having this file under ClearCase control also ensures that all developers are using the same CM settings and scripts. Updating the CM scripts is therefore much easier.