If there is no /usr/atria on your host, check with your system administrator to see if ClearCase was installed at an alternate location. If this is the case, make a note of the alternate installation pathname (for example, /opt/ccase); you'll need to use this pathname when you modify your shell startup script. If ClearCase is not installed at all on your host, consult with your system administrator or see the CASEVision/ClearCase Administration Guide for step-by-step instructions.

First, add the ClearCase bin directory to your executables search path, as shown in Table In-1. The variable ATRIAHOME must be set if ClearCase is installed at a location other than /usr/atria.

You can skip this section if you won't be using ClearCase on-line manual pages at all — for example, if you intend to rely on the help facility built into the ClearCase graphical user interface. You can also skip the rest of this section if you will always use the cleartool man subcommand to access manual pages — it doesn't require a search path.

Users of UNIX-based operating systems are accustomed to using the man(1) command to get on-line documentation. ClearCase includes a comprehensive set of manual pages, accessible in several ways:

The standard man and xman commands can locate manual page files in a variety of locations. These programs can use — but don't require — a search path specified by the environment variable MANPATH. If you wish to read ClearCase manual pages using these programs, add the ClearCase man directory to your manual pages search path, as shown in Table In-2.

---

Note: If your shell startup file does not set the MANPATH environment variable, consult the manual page for the man command itself to determine your system's default search path for manual pages. Then, set MANPATH accordingly in your shell startup script, just before the command(s) that you've copied from Table In-2. For example:

---

% setenv MANPATH /usr/man:/usr/contrib/man:/usr/local/man

ClearCase uses configuration files and environment variables to find various other resources that it may require during processing. In particular, some ClearCase utilities need a way to distinguish different file types (text and binary files, for example) or to find a text editor. The graphical tools, particularly xclearcase, also need access to file typing data, icons and bitmaps, X resource schemes, group files, and text editors.

Unlike the PATH and MANPATH variables, the configuration information for these additional resources is usually predefined, and you do not need to do anything. However, if you choose to customize these resources, or if ClearCase behavior leads you to suspect that some adjustment is required, use Table In-3 to find more information.

---

Note: X resource schemes control the overall appearance of the ClearCase graphical interface.

---

You can skip this section if you intend to use ClearCase only through its graphical user interface (GUI).

When you are working with a UNIX shell program, the current working directory is a very important context. With ClearCase, your shell's view context is equally important. Different views can be configured to “see” your group's development data in different ways; moreover, each view has view-private files that are not visible through any other view.

Confusion and errors are the likely result of entering the right command in the wrong view. To minimize the chances of such an occurrence, modify your shell's prompt string to include the name of the current view, if any. Table In-4 shows code to include in your shell startup script. In a shell that is set to a view, the command prompt will begin with the shell's name (its view-tag), enclosed in square brackets.

The clearmake build program creates derived objects, which are typically shared by multiple users (who wink-in these objects, rather than rebuild them, whenever possible). To promote derived object sharing, you must guarantee adequate permissions (specifically, read and write for group) for derived objects created during clearmake builds. As an alternative to setting your umask value, set the environment variable CLEARCASE_BLD_UMASK:

You can also specify CLEARCASE_BLD_UMASK as a makefile macro. For more information, see CASEVision/ClearCase User's Guide.

Skip this section if you intend to use ClearCase only through its graphical user interface (GUI). Otherwise, you may find it helpful to add command aliases like the following to your shell startup file:

% alias ct cleartool
% alias ctco cleartool checkout
% alias ctci cleartool checkin

After you've made all the modifications to your shell startup script, log out, then log in again. The procedures in the remainder of this chapter will test and verify the changes you've made.

One particularly important host is the network-wide license server host. ClearCase programs refuse to work unless they can obtain an available license from this host; verify your connection with it by entering this command:

% clearlicense
License server on host "saturn".
Running since ...

If this fails because the program clearlicense cannot be found, you made an error in setting up your search path (“Search Path for Executables”). If clearlicense is invoked, but it does not display a message like the one above, see the “Licensing Errors” section of its manual page.

Each ClearCase host in the network has a registry directory: subdirectory rgy of /usr/adm/atria, the ClearCase administration directory. On one network host, the registry server host, the registry directory contains access-path information for all VOBs and views in the local area network. If the command cleartool lsvob lists one or more VOBs, you are properly connected to the registry server host.

If cleartool lsvob fails, display the one-line contents of file /usr/adm/atria/rgy/rgy_hosts.conf. Verify your connection to the named host using any of various OS utilities or their equivalents: ping, rlogin, rsh and so on. If you are still not confident of your connection to the registry server host, consult your system administrator.