Go to the view's host—Log in as the view's owner:

% rlogin earth -l gomez

Determine whether the view has a nonlocal private storage area.

% ls -ld /users/gomez/viewstore/gomez.vws/.s /
    ...   .s -> /public/view_aux/gomez
    (a symbolic link indicates that the private storage area is remote)

Deactivate the view—Use the ps(1) command to determine the process-ID of the view's view_server process. Then, use the kill(1) command to terminate that process.

(if necessary) Validate the private storage area's global pathname—This step is required only if the view's private storage area is remote, and you are moving the view to another host. You must verify that the view's new host can access the private storage area using the same “global pathname” as the view's current host:

% rlogin ccsvr04
% ls /public/view_aux/gomez
  .
  . (this command should succeed)
  .
% exit

If the intended destination host cannot access the view's private storage area in this way, select and validate another host.

Back up the view storage directory—Use the procedure in “Backing Up a View”.

Copy the view storage directory—First, make sure that the desired parent directory of the target location exists and is writable. Then, copy the entire view storage directory tree (but not a remote private storage area) to the new location.

Ensure that the “old” view cannot be reactivated—Remove it from the ClearCase storage registries:

# cleartool rmtag -view -all gomez
# cleartool unregister -view /users/gomez/viewstore/gomez.vws

This prevents reactivation by ClearCase Release 2 client hosts. If your network also includes client hosts running ClearCase Release 1, prevent them from reactivating the view by moving aside the view storage directory:

% cd /users/gomez/viewstore
% mv gomez.vws gomez.vws.OLD

Register the view at its new location.

% cleartool register -view /public/gomez.vws
% cleartool mktag -view -tag gomez /public/gomez.vws

If your network has several network regions, you need to make additional registry entries. This procedure is essentially similar to the one in “Ensuring the VOB's Global Accessibility”.

Reactivate the view.

% cleartool startview gomez

Delete the old view storage directory—Be sure to first verify that the view can be accessed at its new location.

% rm -fr /users/gomez/viewstore/gomez.vws

---

Note: Moving a view does not modify the .view file in the view storage directory. The information in this file always describes the view “first incarnation”.

---

Go to the view's host—Log in as the view's owner:

% rlogin earth -l gomez

Determine whether the view has a nonlocal private storage area.

% ls -ld /users/gomez/viewstore/gomez.vws/.s
   ...   .s -> /public/view_aux/gomez
    (a symbolic link indicates that the private storage area is remote)

Deactivate the view—Use the ps(1) command to determine the process-ID of the view's view_server process. Then, use the kill(1) command to terminate that process.

(if necessary) Validate the private storage area's global pathname—This step is required only if the view's private storage area is remote, and you are moving the view to another host. You must verify that the view's new host can access the private storage area using the same “global pathname” as the view's current host:

% rlogin ccsvr04
% ls /public/view_aux/gomez
  .
  . (this command should succeed)
  .
% exit

If the intended destination host cannot access the view's private storage area in this way, select and validate another host.

Back up the view storage directory—Use the procedure in “Backing Up a View”.

Dump the view's database to ASCII dump files.

% cleartool reformatview -dump /users/gomez/viewstore/gomez.vws

This creates files view_db.dump_file and view_db.state in the view storage directory. It also renames the view database subdirectory to db.dumped.

Copy the view storage directory—First, make sure that the desired parent directory of the target location exists and is writable. Then, copy the entire view storage directory tree (but not a remote private storage area) to the new location.

---

Note: On some systems, the “remote shell” command has another name (for example, remsh).

---

<verify that `/public' already exists on remote host `ccsvr04'>

% cd /users/gomez/viewstore
% tar -cf - gomez.vws | rsh ccsvr04 'cd /public; tar -xBpf -'
    (-B option is not necessary (and not supported on HP-UX systems)

Ensure that the “old” view cannot be reactivated—Remove it from the ClearCase storage registries:

# cleartool rmtag -view -all gomez
# cleartool unregister -view /users/gomez/viewstore/gomez.vws

This prevents reactivation by ClearCase Release 2 client hosts. If your network also includes client hosts running ClearCase Release 1, prevent them from reactivating the view by moving aside the view storage directory:

% cd /users/gomez/viewstore
% mv gomez.vws gomez.vws.OLD

On the new host, recreate the view database from the ASCII dump files.

% rlogin ccsvr04
% cleartool reformatview -load /public/gomez.vws

Register the view at its new location.

% cleartool register -view /public/gomez.vws
% cleartool mktag -view -tag gomez /public/gomez.vws

If your network has several network regions, you need to make additional registry entries. This procedure is essentially similar to the one in “Ensuring the VOB's Global Accessibility”.

Reactivate the view.

% cleartool startview gomez

Delete the backup view database—This backup, named db.dumped, was created by reformatview –load in Step #6.

% rm -fr /public/gomez.vws/db.dumped

Delete the old view storage directory—Be sure to first verify that the view can be accessed at its new location.

% rm -fr /net/sol/users/gomez/viewstore/gomez.vws

Go to the view's host—Log in as the view's owner:

% rlogin earth -l gomez

Deactivate the view—Use the ps(1) command to determine the process-ID of the view's view_server process. Then, use the kill(1) command to terminate that process.

Go to the private storage area—The private storage area is standard UNIX directory tree, with .s as its root.

% cd /users/gomez/viewstore/gomez.vws/.s

Copy the entire directory tree—You can copy the directory tree to a new location using cp, rcp, tar, or other commands. For example:

% mkdir -p /public/view_aux/gomez.priv
% cp -r * /public/view_aux/gomez.priv

Be sure to select a new location that is globally accessible.

Replace the old .s directory with a symbolic link—It doesn't matter whether the existing .s is an actual subdirectory or a symbolic link. Just move it aside and create a (new) symbolic link in its place:

% cd ..
% mv .s .s.MOVED
% ln -s /public/view_aux/gomez.priv .s

Reactivate the view—Use startview or setview.

Remove the private storage area—When you have verified that the private storage pool is working well in its new location, you can remove the old one:

Set the view.

% cleartool setview R2integ

Take inventory of the view's private files with lsprivate—The lsprivate command lists view-private files using the pathnames at which they appear in VOBs:

% cleartool lsprivate | tee /tmp/R2integ.lsp
/vobs/proj/sun4/pick.o
/vobs/proj/sun4/spar.o
/vobs/proj/lib/get.c  [checkedout]
/vobs/proj/lib/get.c~
/vobs/proj/lib/querytty.c  [checkedout]
/vobs/proj/lib/querytty.c~
/vobs/proj/lib/strut.c  [checkedout]
  .
  .

Be sure to place the output in a scratch “inventory” file, as in this example. Don't worry if some not available - deleted perhaps? error messages appear. Such messages are sent to stderr; corresponding information is also written to stdout, and thus will be captured in the scratch file.

Extract the names of unneeded files—Use a text editor, the grep utility, or any other tool to extract from the scratch file the names of files that can safely be deleted. Write this list to another file—for example, /tmp/R2integ.deleteme. Likely candidates include:

Be sure to exclude from the to-be-deleted list any checked-out files. Such files are annotated with [checkedout] in the lsprivate output, as shown above.

Double-check the list—Make sure it contains only files to be deleted.

Delete the view-private files—Use the shell's “command substitution” feature to delete the files in the extracted list:

% rm `cat /tmp/R2integ.deleteme`

---

Note: The following steps are appropriate only if not available - deleted perhaps? error messages appeared in Step #2 above.

---

Decide which stranded files should be deleted—The error messages, and corresponding lines with VOB– and/or DIR– in the inventory file, describe stranded view-private files. Such files belong to VOBs and/or directories that are not currently accessible—and, in some cases, may never become accessible again. Consult the lsprivate manual page to learn more about stranded files, and to decide which files should be deleted. In general, you don't select individual files, but entire directories or entire VOBs, all of whose view-privates files are to be deleted.

Collect the appropriate UUIDs—Determine the UUID of each VOB directory and each VOB whose files are to be deleted. For example, the following lines from lsprivate output describes a stranded file named hello.c.ann:

<VOB-beeb313c.0e8e11cd.ad8e.08:00:69:06:af:65>/
    <DIR-375b5ca0.0e9511cd.ae20.08:00:69:06:af:65>/hello.c.ann

(Here, we've split the line for readability—it is not split in lsprivate's output.) The VOB from which the file is stranded has UUID beeb313c.0e8e11cd.ad8e.08:00:69:06:af:65; the VOB directory in which the stranded file was created has UUID 375b5ca0.0e9511cd.ae20.08:00:69:06:af:65.

Move stranded files to the view's lost+found directory—To remove a set of stranded files, first transfer them to the view's special lost+found directory, using the recoverview command. For example, this command transfers all stranded view-private files created in the same directory as hello.c.ann:

% cleartool recoverview -dir 375b5ca0.0e9511cd.ae20.08:00:69:06:af:65 -tag R2integ
Moved file /net/ccsvr03/vus/integ/.s/lost+found/57FBB6DF.0418.util.c.ann
Moved file /net/ccsvr03/vus/integ/.s/lost+found/2203B56D.00C2.hello.c.ann

In this example, recoverview transfers just two files, util.c.ann and hello.c.ann, to the lost+found directory.

Delete the files from the lost+found directory—You can now use a standard rm(1) command to delete the stranded files:

% cd /net/ccsvr03/vus/integ/.s/lost+found
% rm 57FBB6DF.0418.util.c.ann
% rm 2203B56D.00C2.hello.c.ann