Soft - is your software and documentation Asset - is something that must be protected Management - is what we do Enterprise - is the capability Computing - is the power Services - are what we provide

# ClearCase methods “How do I” covers: (Last updated 11-Nov-09)

Ø  Merging – removing graphical merge arrow, copying, etc...

Ø  Checkout/in – recursive, etc ...

Ø  Types – removing labels recursively, etc...

Ø  Builds – avoid checking errors during, etc...

Ø  Symbolic links – checking out in dynamic views, etc...

Ø  NAS Devices  - moving VOBs between hosts, etc...

Ø  cleartool commands – lshost lsclient, etc...

Ø  Utilities – identifying binary characters in text files, handling binary files, etc...

Ø  Config specs – variations, etc...

Ø  Registry – removing defunct uuid references, etc

Ø  ncaexported – setting up, etc...

Ø  lost+found – emptying using pattern matching, etc...

Ø  Data exchange with IBM Rational – preferred method, etc...

ClearCase methods “How do I” covers: (Last updated 11-Nov-09)

How do I remove an IBM® Rational® ClearCase® AdminVOB (Administrative VOB) hyperlink to disable the connection with a client VOB.

Solution

1.     Run cleartool describe -long of the client VOB or the AdminVOB

2.     Use cleartool rmhlink to break the hyperlink from the cleint to its

3.     Run cleartool describe -long for both the client VOB and its AdminVOB to confirm the hyperlink has been removed

EXAMPLE:

1. Run cleartool describe -long on the client VOB:

F:\childVOB>cleartool describe -long vob:.
versioned object base "\childVOB"
created 28-Sep-01.07:28:09 by jdoe.user@host1
VOB family feature level: 2
VOB storage host:pathname "host1:C:\VOB\childVOB.vbs"
VOB storage global pathname "\\host1\VOB\childVOB.vbs"
database schema version: 54
VOB ownership:
owner ASYLUM\jdoe
group ASYLUM\user
Attributes:
FeatureLevel = 2

3. Run cleartool describe -long again and confirm that the hyperlink has been
removed. Do this for both the client VOB and the AdminVOB.

F:\childVOB>cleartool describe -long vob:.
versioned object base "\childVOB"
created 28-Sep-01.07:28:09 by jdoe.user@host1
VOB family feature level: 2
VOB storage host:pathname "host1:C:\VOB\childVOB.vbs"
VOB storage global pathname "\\host1\VOB\childVOB.vbs"
database schema version: 54
VOB ownership:
owner ASYLUM\jdoe
group ASYLUM\user
Attributes:
FeatureLevel = 2

1.     Set a view and cd into client VOB

%> cleartool setview samecs_view
%> cd /vobs/samece_dev

vob:/vobs/samecs_dev

### 3.        How do I - convert a VOB to an AdminVOB

To change a VOB into an Administrative VOB, you must create an AdminVOB hyperlink from a client VOB to the VOB that you want to act as the AdminVOB.

Note: This can be used to change a newly created VOB or a VOB that was previously an AdminVOB into an AdminVOB.

Example:

There are presently 3 standard VOBs:

/vobs/dev1
/vobs/dev2
/vobs/dev3

To make
/vobs/dev3 into an AdminVOB for /vobs/dev1 and /vobs/dev2:

1.     Make sure all 3 VOBs are mounted and accessible.

3.     Set a view and change directory (cd) into /vobs/dev1
%> cleartool setview sarge
%> cd /vobs/dev1

vob:/vobs/dev1 vob:/vobs/dev3

5.     A describe of the VOB, /vobs/dev1, will now show the hyperlink:
%> cleartool describe -long vob:/vobs/dev1
versioned object base "/vobs/dev1"
created 05-Mar-02.11:43:16 by Sarge(sarge.user@bunker)
VOB family feature level: 3
VOB storage host:pathname
"bunker:/export/home/sarge/store/dev1.vbs"
VOB storage global pathname
"/net/bunker/export/home/sarge/store/dev1.vbs"
database schema version: 53
VOB ownership:
owner atria.com/sarge
group atria.com/user
group atria.com/army
Attributes:
FeatureLevel = 3

Repeat the same steps for each client VOB you want to associate with the AdminVOB.

## Merging

### 4.        How do I - remove a graphical merge arrow which has been drawn between different versions

Remove a graphical merge arrow that has been drawn between versions? First do a cleartool describe on the version from where the Merge arrow emanates:

cleartool desc –l /vobs/samecs/common/imp/src/license.mdb@@/main/15 | grep Merge

Merge@9668@/vobs/samecs -> /vobs/samecs/common/…

Run cleartool rmhlink against the left-hand of the output before the -> merge arrow:

### 5.        How do I - remove a merge hyperlink

How to remove a merge hyperlink in the event that a merge arrow manually created was done so incorrectly.

1.     Open a command prompt.

2.     Start and Set into a view.

3.     Mount and cd into the VOB.

4.     Navigate to the location of the element TO version.

Note: The TO version is the destination of the merge result.

5.     Run a cleartool describe on the version with the hyperlink to be removed.

Example:

cleartool describe -long file.txt@@\main\branch\2

Note: The version extended path (@@\main\branch\2) is only needed when specifying versions other then the one the view is currently selecting.

6.     In the describe output, locate the hyperlink information.

Example:

Merge@1421@\vob <- \vob\src\file.txt@@\main\branch\branch_2\4

Example:

### 6.        How do I - copy the LATEST directory version of a sub-branch to the MAIN LATEST directory version

The actual merge operation requires that there are element versions on both the source, branch A, and the target, branch B, where the resulting versions are a combination of the versions that pre-existed on those branches.

For more details on how the merge works, review the merge algorithm, which is documented in the IBM Rational ClearCase Developing Software manual under Base ClearCase: "Working On a Team" > "Merging".

These instructions will step you through completing a copy of the LATEST element versions on the source, branch A, to the target, branch B, where the resulting versions on branch B will be identical to the versions on branch A.

Note: There will not be a merge arrow created as a result of this procedure between the source and target directories; hence, the procedure is referred to as a copy (merge).

Use these steps to perform a copy (merge) of the exact LATEST directory version of a sub-branch (contains directories and elements and some new elements that do not exist in the MAIN branch) to be the MAIN LATEST directory version.

Note: These examples were created using a dynamic view, however, they will work in a snapshot view, but you must have the source and destination locations loaded into your view.

1.     On UNIX or Linux, this can be done in two steps. First, for the directories so that all of the file elements can be seen on the target branch, MAIN, and then again for the file elements.

2.     On Windows, there are more steps because the command line syntax changes, but it does the same process.

EXAMPLE Scenario:

There is a MAIN branch and a sub-branch, R1.0, in a VOB. After some development, the code on R1.0 needs to be released. The merge to MAIN LATEST will be a duplicate/copy of the R1.0 LATEST version.

Note: This is only an example and the command syntax can be modified to perform the copy to and from alternate branches.

From a view with a default config_spec, do the following:

On UNIX or Linux:

1.     cleartool findmerge . -fversion /main/R1.0/LATEST -type d -merge

2.     cleartool find . -type f -version 'version(.../R1.0/LATEST)' -exec 'cleartool co -nc $CLEARCASE_PN ; cp$CLEARCASE_XPN $CLEARCASE_PN ; cleartool ci -ident -nc$CLEARCASE_PN'

Note: To verify the results of the copy (merge) prior to checking in the directory version on MAIN, you should omit, ; cleartool ci -ident -nc $CLEARCASE_PN', from the command syntax of step #2. Then set to a MAIN LATEST view to confirm the results of the copy merge. If the results are correct, then you can just run the command syntax in step #2. The copy (merge) will just repeat, but nothing new will get copied and the versions will get checked in on MAIN. Otherwise, the checkouts can be canceled by modifying the command syntax of step #2 to run ; cleartool unco$CLEARCASE_PN', instead. The copy operation will repeat, but nothing new will get copied and then the checkouts will get canceled allowing you to back-out of the copy (merge) operation.

On Windows:

1.     cleartool findmerge . -fversion /main/DEV2/LATEST -type d -merge

2.     cleartool find . -type f -version "version(.../main/DEV2/LATEST)" -print -exec "cleartool co -nc %CLEARCASE_PN%"

3.     cleartool find . -type f -version "version(.../main/DEV2/LATEST)" -print -exec "cmd /c copy %CLEARCASE_XPN% %CLEARCASE_PN%"

4.     Use a MAIN LATEST view to verify the results of the copy (merge) prior to proceeding to step #5. The checkouts can be canceled by modifying the command syntax of step #5 to run cleartool unco, instead. This is a method to cancel (or back out) of the operation to start over,

5.     cleartool find . -type f -version "version(.../main/DEV2/LATEST)" -print -exec "cleartool ci -ident -nc %CLEARCASE_PN%"

This will copy everything from the source directory version on the sub-branch to the LATEST directory version created on MAIN. The commands also include directions to perform a check in on the target branch after the copy merge has been completed.

This does not draw the merge arrow for files it only copies over the file and checks it in. In order to draw the hyperlink you can can run a find command similar to the following:

cleartool find . -type f -version "version(/main/branch/LATEST)" -print -exec "cleartool mkhlink -unidir Merge %CLEARCASE_XPN% %CLEARCASE_PN%"

For more information on the cleartool find, cleartool findmerge or any of the cleartool sub-commands used in this technote, refer to the IBM Rational ClearCase Command Reference, or run cleartool man <sub-command>.

Related information

of the cleartool sub-commands used in this technote, refer to the IBM Rational ClearCase Command

### 7.        How do I – understand about merging Microsoft Office files in ClearCase

The Rational ClearCase text file diff and merge tools will only able to compare and merge text files; binary files cannot be merged as detailed in technote 1149498.

The following Microsoft Office files contain binary data that the ClearCase diff-merge utility cannot process or combine correctly:

• Microsoft Word
Note: Using the ms_word type manager for Word documents will allow versions of Word to be merged. Change the element type of the Word documents to ms_word to take advatage of this feature. Review the ClearCase Command Reference Guide on the topic of chtype (
• Microsoft Project
• Microsoft Excel
• Microsoft PowerPoint

WORKAROUND:

A manual merge can be completed, which is essentially a copy operation where the to version is replaced by the from version, but their contents are not consolidated.

### 8.        About Comparing and Merging versions from different elements

Rational ClearCase diff and merge utilities are primarily used to compare/combine text and directory versions of the same element.

However, text versions of different elements can also be compared and merged, while directory versions of different elements can only be compared, not merged.

This functionality can only be initiated from command line, but you can use the -graphical (-g) option with either the cleartool diff or cleartool merge commands to start the graphical user interface (GUI) for these utilities.

Note: Merge arrows cannot be drawn to indicate (or record) that a merge has been completed between versions of different elements.

Compare versions of different text elements

Note: This works the same for comparing versions of different directory elements.

1.     Open a command prompt and issue the cleartool diff -g command:

2.     There is a brief task window that appears and disappears:

3.     The Diff Merge window will open to display the results of the compare operation:

Merge versions of different text elements

1.     Checkout the target file that will be used to capture the merge results.

Checked out "bar.txt" from version "\main\3".

Note: If the target is not checked out first, then an error like the following will appear:

M:\admin_vu\1vob\foo>cleartool merge -to bar.txt bar.txt bar2.txt
Redirecting output of merger to a private file because the specified target "bar.txt" is not a checked out version.
cleartool: Error: Unable to create a merge arrow because the result of the merger is not a VOB version object.
cleartool: Error: Unable to merge to target "bar.txt".

2.     Issue the cleartool merge -g command:

Note: The warning indicates that a merge arrow cannot be drawn.

3.     There is a brief task window that appears and disappears:

4.     The Diff Merge window will open to display the results of the merge operation:

Note: Attempting to merge versions of different directory elements may cause the Diff Merge tool to crash with:

## Checkout and checkin

### 9.        How do I - implement a checkin strategy to check file modifications made prior to checkin completion

You want the ability to check the modifications that you made to a checked out file prior to checking it back in. On checkin, you want to be presented with a choice to either cancel or to proceed with the checkin of a new version (that will include the modifications).

This technote provides an example of a strategy that can be used to provide you with an option to check the modifications that you made in a checked out file using cleartool diff prior to proceeding with its checkin.

Note: This information is provided as an example of how such a strategy may be implemented. The trigger and script explained in this example may need to be customized to your specific environment and tested prior to implementation in a live configuration.

Refer to IBM Rational ClearCase Command Reference Manual under the topic of mktrtype for further information.

EXAMPLE:

1.     Create a file trigger-pre-ci-diff.pl with the following contents:

$file =$ENV{CLEARCASE_PN};
system("cleartool diff -g -pred \"$file\""); system("clearprompt yes_no -prompt \"Checkin?\" -mask yes,no"); exit($?);

Create the following trigger type for all elements of type text_file:

cleartool mktrtype -element -all -eltype text_file -pre checkin -exec "ccperl <path>trigger-pre-ci-diff.pl" PRE_CI_DIFF

This step needs to be done in each VOB where you wish to implement this type of trigger.

### 10.     How do I – understand about searching a VOB for comments

The following are examples of how the lshistory command can be used to search a VOB for comments.

On UNIX® or Linux®:
cleartool lshistory -fmt "%u\t%Sd %o %En %Ln\t%c\n" -minor -recurse | grep "comment" | sort > myfile.txt

On Microsot® Windows®:
cleartool lshistory -fmt "%u\t%Sd %o %En %Ln\t%c\n" -minor -recurse | find
"rmname" | sort > myfile.txt

### 11.     How do I - recursive checkout or checkin using Windows Explorer

In Windows XP Explorer, navigate to the directory where you want to checkout the file.

1.     Right-click on the directory

2.     Click Search to open the Windows Search GUI.

3.     Type *.* in the All or part of the file name field.

4.     Click on More advanced options and unselect Search system folders

Note: Make sure Search subfolders is selected.

5.     Click Search to produce a list of the files from that directory and all subdirectories

6.     Select any or all files in the list, right-click on any file that you selected and click ClearCase > Checkout (or Checkin)

7.     Be sure to click Apply to All

### 12.     How do I - recursively checkout and checkin elements

There is no single command to do a large-scale checkout or checkin. However, this type of checkout can be performed using the cleartool find command:

To perform the equivalent operation using the Windows Explorer interface, see technote 1125301.

CHECKOUT

Note: The additional \" in the Windows command line is to account for file or directory names that contain spaces. This will enclose the element name in quotes, preventing error messages caused by names containing spaces.

IMPORTANT: You will need to know which version of the files to checkout. This example uses the version query to select the LATEST versions on the main branch. Review the ClearCase Command Reference Guide on the topic of find (cleartool man find) for more information.

LIST ALL THE ELEMENTS THAT WILL BE CHECKED OUT (in addition to the current directory)

• UNIX/Linux

myhost% /usr/atria/bin/cleartool ls -l -r
directory version      dira@@/main/3         Rule: element * /main/LATEST

directory "./dira":
version                ./dira/a@@/main/3     Rule: element * /main/LATEST
version                ./dira/b@@/main/3     Rule: element * /main/LATEST
directory version      ./dira/dirb@@/main/3
Rule: element * /main/LATEST

directory "./dira/dirb":
version                ./dira/dirb/c@@/main/3 Rule: element * /main/LATEST

• WINDOWS

M:\def\dmm-vob>cleartool ls -l -r
directory version      dira@@\main\4          Rule: element * \main\LATEST
directory version      lost+found@@\main\0    Rule: element * \main\LATEST

directory ".\dira":
version                .\dira\a@@\main\4      Rule: element * \main\LATEST
version                .\dira\b@@\main\4      Rule: element * \main\LATEST
directory version      .\dira\dirb@@\main\4   Rule: element * \main\LATEST

directory ".\dira\dirb":
version                .\dira\dirb\c@@\main\4 Rule: element * \main\LATEST

RECURSIVE CHECKOUT:

• UNIX/Linux

myhost% /usr/atria/bin/cleartool find . -version 'version(/main/LATEST)' -exec 'cleartool co -nc $CLEARCASE_PN' Checked out "." from version "/main/4". Checked out "./dira" from version "/main/3". Checked out "./dira/a" from version "/main/3". Checked out "./dira/b" from version "/main/3". Checked out "./dira/dirb" from version "/main/3". Checked out "./dira/dirb/c" from version "/main/3". • WINDOWS M:\def\dmm-vob>cleartool find . -version "version(\main\LATEST)" -exec "cleartool co -nc \"%CLEARCASE_PN%\"" Checked out "." from version "\main\5". Checked out ".\dira" from version "\main\4". Checked out ".\dira\a" from version "\main\4". Checked out ".\dira\b" from version "\main\4". Checked out ".\dira\dirb" from version "\main\4". Checked out ".\dira\dirb\c" from version "\main\4". CONFIRM WHAT WAS CHECKED OUT: • UNIX/Linux myhost% /usr/atria/bin/cleartool lsco -all 17-Aug.19:17 user1 checkout directory version "/vobs/dmm-vob/." from /main/4 (reserved) 17-Aug.19:17 user1 checkout directory version "/vobs/dmm-vob/dira" from /main/3 (reserved) 17-Aug.19:17 user1 checkout directory version "/vobs/dmm-vob/dira/dirb" from /main/3 (reserved) 17-Aug.19:17 user1 checkout version "/vobs/dmm-vob/dira/a" from /main/3 (reserved) 17-Aug.19:17 user1 checkout version "/vobs/dmm-vob/dira/b" from /main/3 (reserved) 17-Aug.19:17 user1 checkout version "/vobs/dmm-vob/dira/dirb/c" from /main/3 (reserved) • WINDOWS: M:\def\dmm-vob>cleartool lsco -all 17-Aug.19:58 user1 checkout directory version "M:\def\dmm-vob\." from \main\5 (reserved) 17-Aug.19:58 user1 checkout directory version "M:\def\dmm-vob\dira" from \main\4 (reserved) 17-Aug.19:58 user1 checkout directory version "M:\def\dmm-vob\dira\dirb" from \main\4 (reserved) 17-Aug.19:58 user1 checkout version "M:\def\dmm-vob\dira\a" from \main\4 (reserved) 17-Aug.19:58 user1 checkout version "M:\def\dmm-vob\dira\b" from \main\4 (reserved) 17-Aug.19:58 user1 checkout version "M:\def\dmm-vob\dira\dirb\c" from \main\4 (reserved) CHECKIN Recursive Checkin using the Find command Change to the directory that contains the files to be recursively checked in: • UNIX/Linux: myhost% /usr/atria/bin/cleartool find . -version 'version(/main/LATEST)' -exec 'cleartool ci -nc$CLEARCASE_PN'

Checked in "." version "/main/5".
Checked in "./dira" version "/main/4".
Checked in "./dira/a" version "/main/4".
Checked in "./dira/b" version "/main/4".
Checked in "./dira/dirb" version "/main/4".
Checked in "./dira/dirb/c" version "/main/4".

• WINDOWS:

M:\def\dmm-vob>cleartool find . -version "version(\main\LATEST)" -exec "cleartool ci -nc \"%CLEARCASE_PN%\""

Checked in "." version "\main\6".
Checked in ".\dira" version "\main\5".
Checked in ".\dira\a" version "\main\5".
Checked in ".\dira\b" version "\main\5".
Checked in ".\dira\dirb" version "\main\5".
Checked in ".\dira\dirb\c" version "\main\5".

Recursive Checkin using checkin and lsco commands

The following command syntax can be run on Linux or Solaris to recursively checkin all checkouts for the user running the command:

cleartool ci -nc cleartool lsco -me -short  -r

IMPORTANT: Be aware that recursively checking out or checking in files can cause performance degradation, especially when the total amount of the files exceed 2GB.

It is recommended that if performance is degraded due to this recursive operation that either the operation

be changed (say to checkout/checkin in smaller chunks) or to stop the operation all together.

### 13.     How do I - Checkout (reserved) an element that is already checked out (reserved) in another view

One of two common scenarios is associated with this problem:

1.     An element is checked out (reserved) in a view that still exists and you are unable to checkin the element because:

a.     The checkout is in a snapshot view (and the user is unavailable to perform the checkin or cancel the checkout).

b.     The view is inaccessible.

The view has been removed incorrectly leaving checked out references in the VOB.

Resolving the problem

There are two solutions to this problem:

1. Uncheckout the element(s)

·         If the view exists and you do not care about losing the changes in the view

• If the view no longer exists

See
technote 1122515 which provides instructions on how to remove all the checkout references from a view using the cleartool rmview -uuid command.
2. Change the checkout status of the elements(s) from reserved to unreserved

The element that is checked out reserved can be set to unreserved.

Review the ClearCase Command Reference Guide on the topic of unreserve (cleartool man unreserve) for more information.

There are two scenarios that use slightly different methods to achieve the same results. These scenarios depend on the availability of the view and the ability of a user to start and or set into the view itself.

VIEW IS AVAILABLE

If you can start and set into the view that has the checkouts, but do not want to checkin the data and do not want to lose the changes that were made in that view, you can simply change the reserve status directly in one of two ways:

GUI

1.     From either ClearCase Explorer or Windows Explorer, right click on the element and select Properties of Version

Windows Explorer example:

2.     Uncheck the Reserved check box and click OK to make the version checkedout unreserved.

Command line:

1.     Open a command prompt (Start > Run and type cmd)

2.     Set into the view and cd down to the directory where the element is located.

Example:

M:\>cd my_view\my_vob\docs

3.     Type cleartool unreserve <element_name> to change the reserve status of the checkout.

Example:

M:\my_view\my_vob\docs>cleartool unreserve bar.txt
Changed checkout to unreserved for "bar.txt" branch "\main".

VIEW UNAVAILABLE

This example would be an option for a snapshot view that is currently disconnected from the network which has changes that can't be lost.

Once the element is changed to an unreserved checkout, another view can then check the element out reserved, make changes, and then check it back in.

Command Line:

1.     Open a command prompt (Start > Run and type cmd)

2.     CD into a view down to the directory where the element is located.

Example:

M:\>cd my_view\my_vob\docs

3.     Type cleartool lsco -long <element_name>. This will show which view has this element checked out reserved.

Example:

M:\my_view\my_vob\docs>cleartool lsco -long bar.txt
31-Jul-02.14:17:31     user_name.group@hostname
checkout version "bar.txt" from \main\0 (reserved)
by view: user_view_with_checkout
("
hostname:D:\Views\user_name\user_view_with_checkout.vws")

4.     Type cleartool unreserve -view <view_path> <element_name> to change the reserve status of the checkout.

Example:

M:\my_view\my_vob\docs>cleartool unreserve -view
hostname:D:\Views\user_name\user_view_with_checkout.vws bar.txt
Changed checkout to unreserved for "bar.txt" branch "\main".

5.     Type cleartool lsco -long <element_name> again to verify the file is listed as an unreserved checkout now.

Example:

M:\my_view\my_vob\docs>cleartool lsco -long bar.txt
31-Jul-02.14:17:31     user_name.group@hostname
checkout version "bar.txt" from \main\0 (unreserved)
by view: user_view_with_checkout
("hostname:D:\Views\user_name\user_view_with_checkout.vws")

### 14.     How do I - determine if an unreserved checkout is nonmastered

The cleartool lscheckout command does not list the nonmastered checkout status.

Example:
#>cleartool  lscheckout -long -areplicas
26-Mar-02.09:37:58     jdoe.clearuser@host1
checkout directory version "." from \main\0 (unreserved)
by view: default_view ("host1:D:\views\default_view.vws")

Change request (RFE) RATLC00683548 was submitted to add functionality to allow for lscheckout to identify nonmastered checkouts.

The decision was made by Product Management to exclude the resolution of this enhancement from future upgrades and releases due to the significant architectural changes required to implement the solution.

WORKAROUND:
To determine if an element was checked-out using the –unreserve and the -nmaster options, do the following.

1.     Use the Find Checkouts option from the GUI (Microsoft® Windows® only)

From ClearCase Explorer, right click on the VOB that holds the checkouts (or a subdirectory in the VOB) and select "Find Checkouts".

Select the appropriate options in the Find Criteria screen and click OK.

Note: The output will display the Unreserved, non-mastered checkout status for those checkouts that were performed on a branch that is not locally mastered. Performing a non-mastered checkout at the mastering site will only display the checkout status as Unreserved.

A cleartool describe of the checked out element will display a notation identifying it as a "nonmastered" checkout.

#>cleartool describe -long dir1
directory version ".@@\main\CHECKEDOUT" from \main\0 (unreserved)
checked out 26-Mar-02.09:37:58 by jdoe.clearuser@host1
by view: default_view ("host1:D:\views\default_view.vws")
This is a nonmastered checkout.  It was checked out in replica: patti_rep
Element Protection:
User : dom1\jdoe : rwx
Group: dom1\clearuser : rwx
Other:          : rwx
element type: directory
predecessor version: \main\0

### 15.     How do I - uncheckout files that have been rmnamed

There are two ways to uncheckout a file that has been rmnamed while in a checked out state. The solution depends on the results you are looking for:

UNDO RMNAME & UNCHECKOUT FILE

You can recover from the rmname operation by creating a hard link which points to a version of the directory that contains the file version. Review the ClearCase Command Reference Guide on the topic of rmname (cleartool man rmname) under the section titled Undoing the rmname Command for more information.

Once the name has been restored, you can uncheckout the file.

KEEP RMNAME & UNCHECKOUT FILE

You can uncheckout the file using its fully qualified pathname.

For example, the list checkout (lsco) command might have the following output:

checkout version "/vobs/test_vob/.@@/main/5/test.c" from main 1 (reserved)

Note: The path provided by lsco is the fully qualified path.

To uncheckout the file named test.c (which was rmnamed) use this path as follows:

cleartool uncheckout /vobs/test_vob/.@@/main/5/test.c

### 16.     How do I – understand the Perl script example on how to restrict checkouts to a specific path

The Perl script below is meant to permit a list of users to checkout files or directories so long as the checkout path includes the "permit_path_contains" value.

Note: This script can be copied into a file and called from a trigger.

############

#Trigger permits co if I try to checkout M:\view_1\vob\TEST\TESTDIR\TESTDIR2>cleartool co .

#Trigger DOES NOT permit co if I try to checkout M:\view_1\vob\TEST>cleartool co .

#Trigger permits co if I checkout M:\view_1\vob\TEST cleartool co TESTDIR

##(because TEST\\\\TESTDIR is not in path)

$names_str="user1,user2"; #list of users allowed to checkout$permit_path_contains="TEST\\\\TESTDIR";  #must use 4 backslashes for each directory divider
#Any sub-path listed in the above if part of the checkout path will be permitted
##if the sub-path is not part of the checkout path then fail

print("Permitted users list includes names: $names_str \n"); print("Permitted path includes:$permit_path_contains \n\n");

if ( ($names_str =~ m/$ENV{CLEARCASE_USER}/) && ($ENV{CLEARCASE_PN} =~ m/$permit_path_contains/) )
{ #if current user is in permitted users list && #if checkout path contains permitted sub-path
print("Name $ENV{CLEARCASE_USER} contained within permitted users list$names_str \n");
print("Permitted sub-path $permit_path_contains was found within path$ENV{CLEARCASE_PN} \n");
print("Checkout permitted!\n\n");
exit 0;
}
else
{
print("User not permitted, and or path attempted for checkout not permitted!\n\n");
exit 1;
}
############

## Types

### 17.     How do I – understand about using quotation marks in a ClearCase attribute string value

When attaching an attribute to an object in ClearCase through Cleartool interactive mode, the proper way to escape single quotation marks is to use the ^, carrot symbol.

Example:

cleartool> mkattr -replace -nco My_Attribute '" test ^'this^' "' test.txt

This will create the string value of the attribute to read " test 'this' "

cleartool> mkattr -nco My_Attribute '" test ^'this^' "' test.txt
Created attribute "My_Attribute" on "test.txt@@\main\2".
cleartool> describe -l test.txt@@\main\2
version "test.txt@@\main\2"
created 2008-05-12T19:15:38-04:00 by Deb Jones (user1.user@SC-I)
Element Protection:
User : DOMAIN1\user1 : r--
Group: DOMAIN1\user : r--
Other:          : r--
element type: text_file
predecessor version: \main\1
Attributes:
My_Attribute = " test 'this' "
cleartool> mkattr -replace -nco My_Attribute '" test ^'that^' "' test.txt
Created attribute "My_Attribute" on "test.txt@@\main\2".
cleartool> cleartool> describe -fmt %a\n test.txt@@\main\2
(My_Attribute=" test 'that' ")

Errors:

Failure to use the carrot symbol, ^, to escape the single quotes will yield unfavorable results:

cleartool> mkattr -replace -nco My_Attribute '" test 'this' "' test.txt
cleartool: Error: Invalid string value: "" test ".

Or using an incorrect escape character:

cleartool> mkattr -replace -nco My_Attribute '" test \'this\' "' test.txt
cleartool: Error: Unable to access "this\ "": No such file or directory.
cleartool: Error: Invalid string value: "" test \".

### 18.     How do I – removing labels recursively

To remove a label type and all instances applied to elelements, use the cleartool rmtype command:

cleartool rmtype -rmall -force lbtype:LABEL_NAME@<VOB-tag>

To keep the label type but remove all instances, use the cleartool find command and execute the cleartool rmlabel command.

• Example on UNIX or Linux:

cleartool find . -version "lbtype(REL101)" -exec 'cleartool rmlabel REL101 $CLEARCASE_XPN' • Example on Windows: cleartool find . -version "lbtype(REL101)" -exec "cleartool rmlabel REL101 %CLEARCASE_XPN%" ## Builds ### 19. How do I - prevent of cleartool diff on build files In ClearCase 2002.05.00, the ability to use cleartool diff on build files was added. To do this, ClearCase created two temporary text files that contained copies of the build script, and then ran cleartool diff on the two temporary files. This functionality produced two problems: 1. If the build scripts had lines with over 8000 characters, the diff would fail. (This is a limitation of cleartool diff.) 2. The build scripts and temporary files would end up in the config records, causing them to be larger than usual, with the attendant problems of storage and backup. Problem Change request (RFE) RATLC00766793 was submitted to include functionality to disable the above feature. Note: The new target is available on Windows®, UNIX® and Linux®. When this new target is invoked, it suppresses all information changes, ClearCase will not create the temporary files nor attempt to diff them. Since the diff is prevented, the 8000 character limit never comes into play, and since the temporary files are never created, they are not included in the config record. Resolving the problem To address both of the above issues a new target, NO_PRINT_CMP_SCRIPT has been released in the following patches:  Full ClearCase ClearCase LT 7.0 7.0.0.0-RATL-RCC-IFIX01 2003.06.00 UNIX 2003.06.00 Windows NO_PRINT_CMP_SCRIPT is used at the beginning of a make file, for example: .NO_PRINT_CMP_SCRIPT: foo foo: foo.c /c .o <etc> Note: This make file must be read and understood by all build machines, which requires that any client involved in the build must have the new patch applied before this option will work. ### 20. How do I - avoid checkin errors during a build You can check out, build, and check in during a build, however, the checked in version will not be seen during that build's session. An example makefile following the below logic will cause the existing build not to see newly checkedin files: foo: cleartool checkout -nc$@

build $@ cleartool checkin -nc$@

The build will checkout foo, build it, and check foo back in, but will warn that the newly checked in version is not selected by the view, with a warning such as the following:

cleartool: Warning: Version checked in is not selected by view.

Checked in "foo" version "/main/2".

If the object that is being checked in is a directory, the error will look like this:

cleartool: Warning: Operation "view_readdir_ext" failed: directory not selected in configuration specification.

cleartool: Warning: VOB updated, but view update of uncheckout of "directory_name" failed: directory not selected in configuration specification.

cleartool: Warning: Version checked in is not selected by view.
Checked in "directory_name" version "/main/9".

To avoid any possible problems, merely put off the checkin until the entire build has finished.

For example:

.c.o:

cleartool checkout $@ cc -c$<

all: foo checkin

foo: foo.o

cc -o $@ foo.o checkin: cleartool checkin -nc foo foo.o The checkedout, rebuilt version of foo.o and foo would be available to other processes running within the same build, just like any other DO's would be. Of course, the build scripts would need to add error checking so that the checkout or checkin commands are not executed on files that aren't checked in or out (respectively). This means that the makefile must be carefully worded to avoid this sort of situation. ### 21. How do I – understand about rules with multiple targets and parallel builds This technote identifies a new feature in version 7.0 of IBM® Rational® ClearCase®, where clearmake -J now warns you when a multi-target rule is found in a parallel build on UNIX® and Linux®. Cause Rules with multiple targets may not build correctly in parallel, unless they are declared as a Target Group. Answer This example makefile is not parallel-safe: #Begin makefile foo.h foo.c: foo.y rm -f y.tab.h y.tab.c yacc foo.y mv y.tab.h foo.h mv y.tab.c foo.c #End makefile Although this rule appears intuitively correct, it can cause problems in parallel or distributed builds. The rule does not say that building this target produces both foo.h and foo.c. Rather, the rule says that the build script for foo.h and the build script for foo.c are identical. What's the difference? • If you run clearmake foo.h foo.c, there is none. Built serially, clearmake will run the build script for target foo.h, which will create a sibling DO foo.c as well, and when clearmake evaluates target foo.c it will find a reusable DO in the view and will not rebuild foo.c. • If you run clearmake -J 2 foo.h foo.c, clearmake will not know that these two targets have a special relationship, will launch builds of both of them in parallel, and because they both write the same files, will almost certainly fail one or both targets with interference from another process errors. There is makefile syntax, which correctly identifies these targets as having a special relationship, known as target group syntax. ClearCase support ... • As of version 2003.06.00, clearmake supports this Sun syntax in all compat-modes: foo.h + foo.c: foo.y In GNU compat, it also supports this GNU pattern target group syntax: %.h %.c: %.y • As of version 7.0, clearmake -J -v (or -d) now issues a warning when a target rule with multiple targets, but which is not a target group, is seen. For example: clearmake: Warning: File "Makefile", line 8 foo.h foo.c: Rules with multiple targets may not build correctly in parallel, unless they are declared as a 'target group', like this: a + b: or as patterns in GNU compatibility, like this: %.a %.b: Note: In a non-parallel build configuration, this warning is mostly informational and can be ignored. ## Symbolic Links ### 22. How do I – check out a Symbolic Link (symlink) Targets in dynamic views A ClearCase VOB symlink is a hyperlink that acts as a pointer to data that is actually stored in another location of the same VOB or a different VOB. Symbolic links cannot be checked out. Checkouts (and other related operations) are performed on the ClearCase object that the symlink is attached. Features available in ClearCase Explorer make symlink usage much easier to manage, however, this technote also touches on the command line functionality. The Checkout option for a symlink from ClearCase Explorer executes against the actual symlink target, but from command line, attempts to checkout the symlink will result in an error similar to the following: cleartool: Error: Not an element: "name". Review technote 1220890 for more information on why symlinks cannot be checkedout. Notes: 1. The Symlink option (Symlink Target Operations) only appears in the context menu from ClearCase Explorer after right-clicking on an actual symbolic link. If the symlink target is in another VOB, then that VOB must also be mounted on the local system. 2. The Symlink Target Operations are not available from Microsoft® Windows® Explorer, and the option cannot be added to the Windows Explorer context menu. There are limited features for working with symlinks; right-click the symbolic link > click ClearCase > Explore Link Target | Properties of Symlink. 3. In a snapshot view, the symbolic link target must be loaded in your view also, in order for the Symlink Target Operations to appear. However, these options are limited, such as the checkout does not work, and the alternatives are to either Warp To Symlink Target or use a dynamic view. ClearCase Explorer from a Dynamic view The available Symlink Target Operations from ClearCase Explorer: EXAMPLE: 1. Start ClearCase Explorer, set into a view and locate the symlink in the VOB: 2. Right-click the symlink and click Symlinks: 3. Select Symlink Target Operations > select Checkout: 4. The checkout is of the actual target object and not the symlink; hence, the symlink will not appear checked out: 5. If you access the target object, it will appear as checked out: For more information on symlinks, select Help --> Help Topics -> select Search -> enter symbolic links > click Go!. Command line (CLI) from a Dynamic view This functionality is very basic, in that you can access a directory that is a symlink. However, when you change into that directory, you are actually set into the directory object. Any operations performed in this context are done against the elements in their physical location, and the symlink is only serving as an access point. Note: This example is from Windows, but the functionality is the same on Linux® and UNIX®. EXAMPLE: 1. List out the contents to verify the symlink exist in this directory: M:\admin_vu\vob1\Folder1\sub_dir2>cleartool ls Folder3 --> ../../Folder3 2. Change directory (cd) into the symlink, which puts you into the actual directory object: M:\admin_vu\vob1\Folder1\sub_dir2>cd Folder3 3. Perform a checkout while set in the directory object: M:\admin_vu\vob1\Folder1\sub_dir2\Folder3>cleartool co -nc . Checked out "." from version "\main\4". 4. The symlink will not appear in a checked out state: M:\admin_vu\vob1\Folder1\sub_dir2\Folder3>cleartool ls ..\ ..\Folder3 --> ../../Folder3 5. The directory object will appear as checked out in the describe output: M:\admin_vu\vob1\Folder1\sub_dir2\Folder3>cleartool describe . directory version ".@@\main\CHECKEDOUT" from \main\4 (reserved) checked out 11-May-06.18:06:15 by jdoe.ccgrp@HOST1 by view: admin_vu ("HOST1:C:\Rational\Storage\views\admin_vu.vws") Element Protection: User : DOM\jdoe : rwx Group: DOM\ccgrp : rwx Other: : rwx element type: directory predecessor version: \main\4 Listing the parent directory of the symlink target will also show it as checked out: M:\admin_vu\vob1\Folder1\sub_dir2\Folder3>cleartool ls -l ..\..\.. version ..\..\..\bar.txt@@\main\0 Rule: element * \main\LATEST version ..\..\..\doc3.txt@@\main\0 Rule: element * \main\LATEST version ..\..\..\doc4.txt@@\main\0 Rule: element * \main\LATEST directory version ..\..\..\Folder1@@\main\5 Rule: element * \main\LATEST directory version ..\..\..\Folder3@@\main\CHECKEDOUT from \main\4 Rule: element * CHECKEDOUT ## NAS Devices ### 23. How do I - move VOBs to a different NetApp with the same VOB server How do I move a VOB storage from one Network Appliance (NetApp) to another, while continuing to use the same IBM® Rational® ClearCase® VOB server. 1. Unregister and untag the VOBs from their original location: · · 2. Shut down ClearCase completely on the ClearCase servers and clients. Be sure to confirm that there are no ClearCase processes still running: · 3. Move the VOB storage directories. They can be tarred and moved or the NetApp mirroring utility, NetApp Snapshot technology, can be used; just make sure all the permissions are preserved during the move. 4. Start the ClearCase server, then register and tag the VOBs in their new location: · · 5. Remove or rename the old storage location so it is no longer accessible through the old path. This will ensure that when ClearCase is restarted on the various machines there will be no way to start writing to the old storage locations, instead errors will be revealed immediately and be obvious. 6. Start ClearCase on any remaining servers and then the clients. If there are still some machines that are having problems with accessing the new location of the VOBs, reboot those machines. ## Cleartool commands ### 24. How do I – understand about ClearCase tools in a setuid context Can I use ClearCase tools as child processes of programs/scripts running as setuid? Answer ClearCase tools are neither designed nor tested to run correctly in a setuid context (when the process's effective UID is different from its real UID). If you need to start a ClearCase tool from your own tools that are running setuid, your tools should fork a child process, set its real and effective UIDs to the same value (for example, with setuid(getuid()), then execute the ClearCase tool. ### 25. How do I -identify which container is not referenced in the output of checkvob -debris How can you identify which container is not referenced from the output of an IBM Rational ClearCase checkvob -debris command? Cause This is a general technote that provides information about ClearCase and the checkvob -debris command output. Answer Refer to the IBM Rational ClearCase Administrators Guide under the following topics for further details explaining what is considered debris. Source pool: Unreferenced container (debris) Missing and unreferenced data containers The following example shows how you can identify the proper container: 1. Simulate a VOB with an unreferenced container (do this using a test VOB). This can be done by copying any container to any other location in the pool (within the directory structure: <vob-storage-dir>\xml_vob.vbs\s\sdft). 2. Run checkvob with -debris on that VOB (without the -fix option ), the output will return : cleartool> checkvob -view xml_view -protections -debris -pool \\99GAAXV\alexshare\vobstorage\xml_vob.vbs 6 containers checked (20 kbytes) 1 unreferenced but under age (6 kbytes) 0 unreference d but maybe needed (0 kbytes) 3. As you notice so far we do not have the container id . Now we will run checkvob with the -fix option (to fix the damage) : cleartool> checkvob -view xml_view -protections -debris -pool -fix \\99GAAXV\alexshare\vobstorage\xml_vob.vbs This step should prompt you to fix the container (either use -force or answer yes ). As a result the container will be moved into the "lost+found " inside the sdft pool in the VOB storage (not the lost+found of the VOB). C:\alexshare\vobstorage\xml_vob.vbs\s\sdft\lost+found ### 26. How do I – understand the additional examples of the cleartool find command The cleartool find command is used to locate ClearCase objects within a VOB, and is not restricted by the view's configuration specification (config spec). There are various switches and options available for this command, refer to cleartool man find, or the IBM Rational ClearCase Command Reference for more details. Note: It is not possible to list the elements in a single directory using the cleartool find command. This command operates on file attributes or metadata, and there is no method to query upon a file's location within a directory. All the versions that get returned are for elements that are located in or below the working directory. LOGICAL OPERATORS: The cleartool find command can be used with the QUERY LANGUAGE to take advantage of logical operators. Review the IBM Rational ClearCase Command Reference Guide on the topic of query_language (cleartool man query_language) for more details. Example: Use the cleartool find command with the logical not (!) & and (&&) operators to find all versions for an element that are not labeled with either of two label types in the VOB. cleartool find . -version !"lbtype(tested) && !lbtype(release) " -print About *_sub query primitives When using the ClearCase find command in what circumstances should the *_sub query primitives (attype_sub, label_sub and attr_sub) be used instead of just lbtype or attype? When the type being queried does not apply to the "level" (-element -branch -version) being queried. For example, query for a label using -element ... labels are only on versions within elements Or When searching recursively through the levels for all matches. For example, query for an attribute using -element, attr_sub would recursively search element, branches AND versions of the element for that attribute. Example: Excluding any elements that do not have both labels, list all versions in the current VOB labeled either REL1 or REL2 but not both. cmd-context find -all -element '{lbtype_sub(REL1) && lbtype_sub(REL2)}' ^ -version '{(lbtype(REL1) && ! lbtype(REL2)) || ^ (lbtype(REL2) && !lbtype(REL1))}' -print \dev\testfile.txt@@\main\43 \dev\testfile.txt@@\main\68 \dev\util.c@@\main\50 \dev\util.c@@\main\58 ... - (ClearCase only) List each header file (*.h) for which some version is labeled REL2 or REL3. cmd-context find . -name '*.h' -element 'lbtype_sub(REL2) ^ || lbtype_sub(REL3)' -print .\hello.h@@ Without the _sub: cmd-context find . -version 'version(\main\LATEST) && ! lbtype(REL3)' ^ -exec 'cleartool mklabel -replace REL3 %CLEARCASE_XPN%' REDIRECT OUTPUT TO A FILE: When running a cleartool find command the text can run off the screen, but you can redirect the output to a text file. To capture the data to a file for viewing, printing or use by a script (or other program) the output can be redirected as follows: 1. To get the STDOUT information add " > file_name.txt" to the end of the command string: · cleartool find . -all -print > c:\out.txt 2. To get both STDOUT and STDERR information add " > file_name.txt 2>&1" to the end of the command string: · Windows -- cleartool find . -all -print > c:\out.txt 2>&1 · UNIX/Linux -- cleartool find . -all -print >& /tmp/out.txt SPECIFIC EXAMPLES: Examples of the cleartool find command usage: • Find the latest versions of all elements in a directory and execute a cleartool rmname on them: cleartool find . -version version(\main\LATEST) -exec 'cleartool rm %CLEARCASE_PN%' • Find an element with a particular name: cleartool find . -name "file name" -print • Find all the latest versions of all files with a .txt extension and list those versions: cleartool find . -name "*.txt" -version version(\main\LATEST) -print • Find the latest version of elements with a particular string in their name and list those versions: cleartool find . -name "*ada*" -version version(\main\LATEST) -print • Find all element versions with a given label that are not on a given branch: Windows: cleartool find -all -version "lbtype_sub(MYLABEL) && !brtype(mybranch)" -print UNIX and Linux: cleartool find -all -version 'lbtype_sub(MYLABEL) && !brtype(mybranch)' -print • Find checkouts on a specific branch: Windows: Checked out on main: M:\base_dmhnt_view\Support>cleartool find . -version "brtype(main)" -print | find "CHECKEDOUT" .@@\main\CHECKEDOUT Checked out on branch, BR3: M:\base_dmhnt_view\Support>cleartool find . -version "brtype(BR3)" -print | find "CHECKEDOUT" .\coocoo.exe@@\main\BR3\CHECKEDOUT UNIX and Linux: Checked out on main: /usr/atria/bin/cleartool find . -version "brtype(main)" -print | grep CHECKEDOUT .@@/main/CHECKEDOUT Checked out on branch, BR3: /usr/atria/bin/cleartool find . -version "brtype(BR3)" -print | grep CHECKEDOUT ./coocoo.exe@@/main/BR3/CHECKEDOUT • Find, list out and count the number of elements in VOB, refer to technote 1125941 • Find and list dates when a particular label was attached to all versions: It is sometimes important to know when a given label was applied to a version of an element, as opposed to when that version was created. This note explains the process used for to create the command line to display the desired information. Example: To report the date when the cleartool mklabel command was issued on element foo.c for attaching version label REL1, use the following command: UNIX and Linux: % cleartool lshistory -minor lbtype:REL1 foo.c Windows: cleartool lshistory -minor lbtype:REL1 foo.c To generate the list of those elements which contain a version with a predetermined label (REL1) attached, use the following syntax of the cleartool find command: UNIX and Linux: % cleartool find -all -element '{lbtype_sub(REL1)}' -print Windows: cleartool find -all -element "{lbtype_sub(REL1)}" -print The solution is the combination of the cleartool find command with the cleartool lshistory command as follows: UNIX and Linux: % cleartool find -all -element '{lbtype_sub(REL1)}' -exec 'cleartool lshistory -minor lbtype:REL1$CLEARCASE_PN'

Windows:
cleartool find -all -element "{lbtype_sub(REL1)}" -exec "cleartool lshistory -minor lbtype:REL1 %CLEARCASE_PN%"

To reduce the output from the command above to include only those lines which report the date when mklabel was issued, add the following grep or find command:

UNIX and Linux:

% cleartool find -all -element '{lbtype_sub(REL1)}' -exec 'cleartool lshistory -minor lbtype:REL1 $CLEARCASE_PN' | grep 'make label' Windows: M:\admin_vu\vob1>cleartool find -all -element "{lbtype_sub(REL1)}" -exec "cleartool lshistory -minor lbtype:REL1 %CLEARCASE_PN%" | find "make label" • Find all labeled or non-labeled versions that are selected by the view, you can use the combination of -cview and -version with cleartool find in order to achieve the desired result: To print all the versions selected by your view: cleartool find . -cview -print To print all versions selected by your view that have a LABEL applied: cleartool find . -cview -version "lbtype(LABEL)" -print To print all versions from your view that do not have the LABEL applied: cleartool find . -cview -version "!lbtype(LABEL)" -print To find versions in which two labels do not exist: cleartool find . -ver "! lbtype(REL1) && ! lbtype(REL2) && version(.../main/LATEST)" -print To find all elements with any label: Windows: cleartool find . -type f -exec "cleartool lsvtree -a %CLEARCASE_PN%" | findstr "(" ./hello.c@@/main/1 (LABEL100, LABEL99, LABEL98, LABEL97) ./foo.xml@@/main/BR1/1 (REL2) ./bar.o@@/main/1 (REL1) UNIX/Linux: cleartool find . -type f -exec 'cleartool lsvtree -a$CLEARCASE_PN' | grep "("

./hello.c@@/main/1 (LABEL100, LABEL99, LABEL98, LABEL97)
./foo.xml@@/main/BR1/1 (REL2)
./bar.o@@/main/1 (REL1)
• Find and listing symbolic links:

UNIX and Linux:

There are two ways this can be done.

1. cleartool find -all -type l -exec '/usr/atria/bin/cleartool describe $CLEARCASE_PN' Example: % cleartool find -all -type l -exec '/usr/atria/bin/cleartool describe$CLEARCASE_PN'
created 25-Feb-03.12:34:39 by Joe_USER (joeuser.syb@lemur)
Protection:
User : joeuser : rwx
Group: syb   : rwx
Other:          : rwx
created 16-Apr-03.14:02:17 by Joe_USER (joeuser.syb @lemur)
Protection:
User : joeuser : rwx
Group: syb   : rwx
Other:          : rwx

2. cleartool find -all -type l -print

Example:

%> cleartool find -all -type l -print

Windows:

1. cleartool find . -type l -exec "cleartool describe -fmt \"%n %[slink_text]Tp\n\" \"%CLEARCASE_PN%\""

Example:
Y:\VOB_A>cleartool find . -type l -exec "cleartool describe -fmt "%n %[slink_text]Tp\n\n\" \"%CLEARCASE_PN%\""

Note: In the example above, the file createsymlink.txt is located in VOB_A and a symbolic link to this file was created in the SymlinkFolder in VOB_B.

2. cleartool find -all -type l -print

Example:
Y:\VOB_A>cleartool find -all -type l -print
Y:\VOB_A\import2@@\main\10\migration9
Y:\VOB_A\import2@@\main\9\migration8
• Find latest labels

UNIX:

cleartool lshistory -minor <DIRECTORY> |grep "make label" |grep <element name>

Note: Removing the last grep from the command will list all labels created in that directory.

Windows:

cleartool lshistory -minor -r . |findstr /C:"make label"

• Find and label all element versions before a certain date and time:

Get all the files in a VOB and store that data in a flat file:

cleartool find <vobtag> -all -print > <filename1>
or
cleartool find <vobtag> -version -print > <filename>

Get all the files created after the target date/time and store that data in a flat file:

cleartool find <vobtag> -element "{created_since(target-data-time)}" -print > <filename2>
or
cleartool find <vobtag> -version "{created_since(target-data-time)}" -print > <filename2>

Compare the two files to get the 'before version set'.

Do this by taking the first entry in filename2, then going to filename1 and taking everything that occurs before that line in filename1:

Save that in a new file, <filename3>

For every entry in <filename3> execute:

cleartool mklabel <labelname>

First you should change the view's config spec to look at the desired branch.

Then run a sample find command to verify the list of versions that would be labeled:
cleartool  find . -version 'version(.../bugs/LATEST)' -print                    .@@/main/bugs/1

./bar.c@@/main/bugs/1

./foo.c@@/main/bugs/2

Once the above list if verified, modify the find command to include the mklabel command to apply the label to those versions:

cleartool find . -version 'version(.../bugs/LATEST)' -exec 'cleartool mklabel REL3  $CLEARCASE_PN' Created label "REL3" on "." version "/main/bugs/1". Created label "REL3" on "./bar.c" version "/main/bugs/1". Created label "REL3" on "./foo.c" version "/main/bugs/2". • Find all elements or versions created between a specific date and time: Examples: To find elements created between two dates and times: cleartool find . -element "{created_since(date1) && !created_since(date2)}" -print To find versions created between two dates and times: cleartool find . -version "{created_since(date1) && !created_since(date2)}" -print To narrow the search by user, add -user or created_by, such as to find elements created between date1 and date2 by user1 and modified by user2: cleartool find . -user user1 -element "{created_since(date1) && !created_since(date2) && created_by(user2)}" -print Using the query language, you can also restrict the output to specific branches, such as to find versions created since date1 on BRANCH and modified by user1: cleartool find . -version "{brtype(BRANCH) && created_since(date1) && created_by(user1)}" -print • Find all file elements in a VOB with a particular extension and change the protections: Examples to find all file elements in a VOB with a particular extension and change the protections: To find all .exe file elements with no spaces in the filenames and add the execute bit for the user ownership: cleartool find . -all -name *.exe -print -exec "cleartool protect -chmod u+x -file %CLEARCASE_PN%" This will find all .bat file elements that have spaces in the filenames and add the execute bit for the group ownership: cleartool find . -all -name *.bat -print -exec "cleartool protect -chmod u+x -file ""%CLEARCASE_PN%""" Note: The syntax can be modified as needed to find different file types and set the protections. Also, the additional quotations are needed to pick filenames that contain spaces. • Find and change ownership of all objects in a UCM PVOB or Component VOB, refer to technote 1146517 • Find and recursively check out elements, refer to technote 1122520 • Find and remove labels recursively, refer to technote 1126736 • Find all triggers associated with an element, refer to technote 1120633. • To List all branches on all elements run the cleartool find command in a directory and search for branches that do NOT have a non-exististent attribute. For example... cleartool find . -branch '\!attype(dummyname)' -print .@@/main ./A1.txt@@/main ./A1.txt@@/main/A ./A1.txt@@/main/A/B ./A1.txt@@/main/A/B/D ./A1.txt@@/main/A/C ./A1.txt@@/main/A/E ./D1@@/main ./D1/D2@@/main ./D1/aaa@@/main ./E1@@/main ./E1/D2@@/main ./E1/aaa@@/main ./lost+found@@/main ./main.c@@/main ./mergeTo.xml@@/main ./mergeTo.xml@@/main/BR1 • Windows example: Search the text within a file to find all instances of a particular string: Note: Uses the Windows for command. for /f %a in ('cleartool lsvtree -all <ELEMENT NAME>') do find "<STRING>" %a where: <ELEMENT NAME> = element which version tree you wish to check <STRING> = the search string you wish to look for. Example: M:\view\my_test_vob>for /f %a in ('cleartool lsvtree -all test.txt') do find "hi" %a Access denied - TEST.TXT@@\MAIN ---------- TEST.TXT@@\MAIN\0 ---------- TEST.TXT@@\MAIN\1 hi ---------- TEST.TXT@@\MAIN\2 hi • Find all hyperlinks in a VOB and describe them (or run checkvob against them). cleartool find . -all -kind all -exec "cleartool describe -ahlink -all \"%CLEARCASE_XPN%\"" Note: If needed the 'describe -ahlink -all' can be replace by a 'checkvob -hlinks', • Find a particular string in a comment by searching all versions of all elements in a VOB. Note: Example syntax includes formatting for the version and the comment: UNIX/Linux: cleartool find -all -ver "! lbtype(<non-existing label>)" -exec 'cleartool desc -fmt "Version: %n\tComment: %c\n\n"$CLEARCASE_XPN' | grep <the string you are looking for>

Windows:
cleartool find -all -ver "! lbtype(<non-existing label>)" -exec "cleartool desc -fmt  \"Version: %n\tComment: %c\n\n\" %CLEARCASE_XPN%" | findstr "<the string you are looking for>"
• Find the value of a specific hyperlink:

The following command will return a "describe" on each element that is found with the type in the find command.

cleartool find . -version "hltype(Merge)" -nxname -exec 'cleartool desc $CLEARCASE_PN' -print From the output of this command the user will get a list of all the elements. Then the user will then need to create a script to parse this output and extract just the names. • Replacing label names in a ClearCase VOB In the examples below, label type REL1 is replaced with REL2. 1) If the label type is not globally, simply use the rename command: cleartool rename lbtype:REL1 lbtype:REL2 2) If, in fact, the label is globally defined, this command will result in the following error message: cleartool: Error: Operation "rename" not allowed on the local instance of a global label type. cleartool: Error: Unable to rename label type from "REL1l" to "REL2". Thus, for globally defined label types, it is necessary to use a two step process of: - adding REL2 to all instances of REL1 - removing the REL1 labels Here are the steps in detail: a) First, create the label type REL2: cleartool mklbtype REL2 b) Find the elements that already have REL1 attached to them so that the new REL2 label can be attached: cleartool find . -ver lbtype(REL1) -exec "cleartool mklabel REL2 %CLEARCASE_PN%" c) Remove all instances of the REL1 label: cleartool find . -ver lbtype(REL1) -exec "cleartool rmlabel REL1 %CLEARCASE_PN%" d) If desired, remove the REL1 label type: cleartool rmtype -rmall lbtype:REL1 • Counting the number of versions in a VOB Within the VOB, use the command, "cleartool find . -exec 'cleartool lsvtree -a$CLEARCASE_PN' |wc -l". This counts the number of versions in the VOB, including those that are checked out.
• How to Checkout all elements in a VOB

From the root of the VOB:

On Windows:

cleartool find . -type dfl -exec "cleartool checkout %CLEARCASE_PN%"

On UNIX:

cleartool find . -type dfl -exec 'cleartool checkout $CLEARCASE_PN' • How to list element versions on a branch but exclude checkedout versions The first example lists all element versions including any CHECKEDOUT versions. The second example shows how to list all element versions, but excluding any CHECKEDOUT versions. EXAMPLE 1: > cleartool find . -version "brtype(bugfix)" -print ./a.c@@/main/bugfix/0 ./a.c@@/main/bugfix/1 ./a.c@@/main/bugfix/2 ./a.c@@/main/bugfix/CHECKEDOUT ./golf.c@@/main/bugfix/0 ./golf.c@@/main/bugfix/1 EXAMPLE 2 > cleartool find . -version "brtype(bugfix)" -print | grep -v CHECKEDOUT ./a.c@@/main/bugfix/0 ./a.c@@/main/bugfix/1 ./a.c@@/main/bugfix/2 ./golf.c@@/main/bugfix/0 ./golf.c@@/main/bugfix/1 • Create a trigger that will change the ownership to a single owner To create a postop checkin trigger that will change the ownership. The example of the trigger is as follows: Z:\mac>cleartool mktrtype -element -all -postop checkin -eltype -all -nc -exec "cleartool protect -chown vobadmin -chgrp user %CLEARCASE_PN%" CHOWN_CHGR Created trigger type "CHOWN_CHGR". Z:\mac>ct describe new.txt version "new.txt@@\main\3" created 19-Jul-01.11:21:13 by foo.user@dingdong Element Protection: User : foo: r-x Group: user : r-x Other: : r-x element type: compressed_file predecessor version: \main\2 Labels: project1_11_30_01.246 project1_11_09_01a.246 TEST NEW MIKEY When you checkout the item, make your changes and then check it in, the trigger will fire and the ownership will change. Z:\mac>ct co new.txt Checkout comments for "new.txt": . Checked out "new.txt" from version "\main\3". Z:\mac>ct ci new.txt Checkin comments for "new.txt": . Changed protection on "Z:\mac\new.txt". Checked in "new.txt" version "\main\4". Z:\mac>ct describe new.txt version "new.txt@@\main\4" created 27-Feb-02.16:41:12 by foo.user@dingdong Element Protection: User : vobadmin : r-x Group: user : r-x Other: : r-x element type: compressed_file predecessor version: \main\3 ==> Here's the syntax for the trigger so it will work on both Windows and UNIX: Z:\mac>cleartool mktrtype -element -all -postop checkin -eltype -all -nc -execunix "cleartool protect -chown vobadmin -chgrp user$CLEARCASE_PN"
-execwin "cleartool protect -chown vobadmin -chgrp user %CLEARCASE_PN%"
CHOWN_CHGR

Note: The user and group specified in the cleartool protect command must be valid in the Windows or UNIX environment that the trigger fires in. If not, then the reprotect will not succeed and the ownership will remain unchanged.
• Example optimizing the cleartool find command:

The below 'ct-find' commands both return the same result set, but the first one takes *hundreds of times longer*!!!.

The second find isn't faster just because caches are loaded per the first run or anything like that. Going to a new replica and running the optimized find first still gives results in a couple seconds while even then the slower find run subsequently takes minutes still.

Cleartool find is slower when you are not scoping to the -branch level before looking for the httype criteria on every single "-version" in the element's vtree

my-view1:7> date ; ct find /vob/cc/sys/makesubsys -follow -dir -version '(hltype(Merge, <-) || hltype(Merge, -> )) && brtype(main)' -print;date Tue Apr 24 11:04:15 PDT 2007
/vob/cc/sys/makesubsys@@/main/71
/vob/cc/sys/makesubsys@@/main/86
/vob/cc/sys/makesubsys@@/main/87
/vob/cc/sys/makesubsys@@/main/88
/vob/cc/sys/makesubsys@@/main/89
/vob/cc/sys/makesubsys@@/main/90
/vob/cc/sys/makesubsys@@/main/91
/vob/cc/sys/makesubsys@@/main/92
/vob/cc/sys/makesubsys@@/main/93
/vob/cc/sys/makesubsys@@/main/94
/vob/cc/sys/makesubsys@@/main/95
/vob/cc/sys/makesubsys@@/main/96
Tue Apr 24 11:16:28 PDT 2007

my-view1:8> date; ct find /vob/cc/sys/makesubsys -follow -dir -branch 'brtype(main)' -version '(hltype(Merge, <-) || hltype(Merge, ->))' -print;date Tue Apr 24 11:35:40 PDT 2007
/vob/cc/sys/makesubsys@@/main/86
/vob/cc/sys/makesubsys@@/main/87
/vob/cc/sys/makesubsys@@/main/88
/vob/cc/sys/makesubsys@@/main/89
/vob/cc/sys/makesubsys@@/main/90
/vob/cc/sys/makesubsys@@/main/91
/vob/cc/sys/makesubsys@@/main/92
/vob/cc/sys/makesubsys@@/main/93
/vob/cc/sys/makesubsys@@/main/94
/vob/cc/sys/makesubsys@@/main/95
/vob/cc/sys/makesubsys@@/main/96
/vob/cc/sys/makesubsys@@/main/71
Tue Apr 24 11:35:42 PDT 2007
• How to find elements/versions on a specific branch in multiple VOBs:

Version: cleartool find -avobs -version "brtype(branch)" -print

Element: cleartool find -avobs -element "brtype(branch)" -print

How to find elements and versions with specific comments

I want to find all elements/versions with specific comments like “Jane changed this on 11-26”

M:\my_base_view\my_base_vob>cleartool find -all -exec "cleartool lshistory -minor -fmt \"%n\t%c\n\" \"%CLEARCASE_XPN%\"" >c:\output.txt

**This will pipe the output to a file and you would have to grep the file for the specific comments you're looking for.

M:\my_base_view\my_base_vob>cleartool find . -version !"lbtype(LABEL_NAME)" -exec "cleartool describe -long %CLEARCASE_PN%" >c:\output2.txt

**This will search for a nonexistent label

### 27.     How do I - display only the current VOB owner's username using the cleartool describe command

By default, the domainname/username is displayed when running a cleartool describe of a VOB using this syntax:

cleartool desc -fmt "%[owner]p\n" vob:<vob_tag_name>

Example:
prompt% cleartool desc -fmt "%[owner]p\n" vob:/myvob

domainame.com/johndoe

Use this syntax to display the user the username without the domain.

Example:
cleartool desc -fmt "%[owner]p\n" vob:/myvob  | cut -d"/" -f2

johndoe

Note: The double quotes are required for the delimiter "/" for the cut command.

### 28.     How do I - determine what versions of ClearCase and operating systems are installed on individual hosts

To determine what ClearCase versions and operating systems are installed on the ClearCase host machines, you can use cleartool lsclients or cleartool hostinfo commands to get a list of all clients in the environment. This information can be helpful for administrative purposes.

EXAMPLE:

• Display installed ClearCase version and operating system information for all clients of a specific license or registry server:

buildtest: ClearCase 2003.06.10+ (Windows NT 5.1 (build 2600) Service Pack 2 Pentium)
OwnTest: ClearCase 7.0.0.1 (Windows NT 5.2 (build 3790)  Pentium)
MYTEST: ClearCase 2003.06.10+ (Windows NT 5.1 (build 2600) Service Pack 2 Pentium)
abc-bf: ClearCase 7.0.0.0-IFIX02 (Windows NT 5.1 (build 2600) Service Pack 2 Pentium)
linus0: ClearCase 2003.06.10+ (Linux 2.4.21-15.EL #1 Thu Apr 22 00:27:41 EDT2004 i686)
mysol: ClearCase 2003.06.10+ (SunOS 5.10 Generic_118855-14 i86pc)

Note: For clients running ClearCase 2003.06.xx versions it lists the version as 2003.06.10+
• Display configuration data for one or more hosts

cleartool hostinfo -properties <hostname>
<hostname>: ClearCase 2003.06.10+ (HP-UX B.11.00 U 9000/785)
Backup registry host: bigwig
Installed product: ClearCase version 2003.06.00 (Fri Apr 25 09:06:30 EDT 2003)

Installed product: clearcase_p2003.06.00-3 (Thu Jan 29 16:37:58 EST 2004)
Installed product: clearcase_p2003.06.00-14 (Thu Dec 02 15:33:25 EST 2004)
Installed product: clearcase_p2003.06.00-15 (Thu Dec 02 06:37:35 EST 2004)
Installed product: clearcase_p2003.06.00-16 (Fri Dec 03 14:57:40 EST 2004)
Installed product: multisite_p2003.06.00-6 (Fri Dec 03 09:14:05 EST 2004)
Installed product: clearcase_p2003.06.00-36 (Fri Apr 21 15:10:24 EDT 2006)
Installed product: 2006B multisite_p2003.06.00-14 (Fri Jun 30 11:15:59 EDT 2006)
Installed product: clearcase_p2003.06.00-37 (Fri Jun 30 15:14:40 EDT 2006)
Installed product: clearcase_p2003.06.00-38 (Fri Jun 30 08:20:07 EDT 2006)
Installed product: MultiSite version 2003.06.00 (Fri Apr 25 09:06:30 EDT 2003)

Installed product: multisite_p2003.06.00-6 (Fri Dec 03 09:14:05 EST 2004)
Installed product: multisite_p2003.06.00-14 (Fri Jun 30 11:15:59 EDT 2006)

cleartool hostinfo -properties my-host
my-host: ClearCase 7.0.1.2 (Windows NT 5.1 (build 2600) Service Pack 2 Pentium)
Registry interoperability region: unix_region
Scaling factor to initialize MVFS cache sizes: 1
MVFS cache sizes:
Free mnodes: 1800
Free mnodes for cleartext: 1800
File names: 2400
Directory names: 600
RPC handles: 15
Initial mnode table size: 12288
Blocks per directory: 6
Minimum free mnodes: 1620
Minimum free mnodes for cleartext: 1704
VOB hash table size: 512
Cleartext hash table size: 128
DNC hash table size: 541
Process hash table size: 511
Installed product: MultiSite version 7.0.1 (Fri May 9 19:45:26 2008)
Installed product: MultiSite version 7.0.1 (Thu May 17 09:19:04 2007)
Installed product: MultiSite version 7.0.1_iFix01 (Wed Sep 19 11:15:35 2007)
Installed product: MultiSite version 7.0.1.1 (Wed Nov 28 17:43:33 2007)
Installed product: MultiSite version 7.0.1.1_iFix01 (Tue Feb 12 10:49:03 2008)
Installed product: MultiSite version 7.0.1.1_iFix02 (Wed May 14 23:53:47 2008)
Installed product: MultiSite version 7.0.1.2 (Fri Jul 18 12:43:53 2008)
Installed product: ClearCase version 7.0.1 (Thu May 17 09:19:01 2007)
Installed product: ClearCase version 7.0.1_iFix01 (Wed Sep 19 11:15:35 2007)
Installed product: ClearCase version 7.0.1.1 (Wed Nov 28 17:43:24 2007)
Installed product: ClearCase version 7.0.1.1_iFix01 (Tue Feb 12 10:48:57 2008)
Installed product: ClearCase version 7.0.1.1_iFix02 (Wed May 14 23:53:33 2008)
Installed product: ClearCase version 7.0.1.2 (Fri Jul 18 12:43:48 2008)

Note: The output above may include an error message "
adm_prop_get_mvfs_settings_if_V1: RPC: Procedure unavailable" which is expected if you run the hostinfo command against a host running an older version of ClearCase.

### 29.     How do I - Change ownership of all objects in a VOB using the find command

How can I change the ownership of all objects in an IBM® Rational® ClearCase® VOB (including UCM Component and/or Project VOBs) on Microsoft® Windows®, UNIX® and Linux® using the cleartool find command?

When a VOB's ownership is changed it is often desirable to change the ownership of the elements and metadata in the VOB. You can use the cleartool find command in conjunction with the protect command to reprotect the objects in the VOB.

Notes:

• These directions are applicable for use in UCM and Base ClearCase when working in an AdminVOB and Child VOB configuration.
• On Windows, the vob_sidwalk command can be run to accomplish the same goal. Review technote 1256390 for more details.

Example:

The following commands will change the owner and group for all the metadata and elements in a PVOB or Component VOB on UNIX.

Note: The individual commands below must be run in each of the VOBs needing reprotection.

1. To change the owner and group of every type object in a VOB:

• Set into a view with a default config_spec.
• Set to the VOB tag.
• Execute the following find command:

UNIX and Linux:

cleartool find . -kind all -exec 'cleartool protect -chown NEWUSER -chgrp NEWGROUP $CLEARCASE_PN' Windows: cleartool find . -kind all -exec "cleartool protect -chown NEWUSER -chgrp \"RATIONAL\Domain Users\" \"%CLEARCASE_PN%\"" Note: The -kind option is present in 2003.06.00 and can be used, but is undocumented. This option is documented in 7.0 or later. The usage of -kind is: -kind { object_selector | all } 2. To change the owner and group of all the elements in a VOB: • Set into a view with a default config_spec. • Set to the VOB tag. Execute the following find command: UNIX and Linux: cleartool find . -all -exec 'cleartool protect -chown NEWUSER -chgrp NEWGROUP$CLEARCASE_PN'

Windows:

cleartool find . -all -exec "cleartool protect -chown NEWUSER -chgrp \"RATIONAL\Domain Users\" \"%CLEARCASE_PN%\""

### 30.     How do I - optimize the cleartool find -version -branch command for performance improvements

Specifying the -branch option before -version can significantly increase performance of the cleartool find command.

Example:

For this example the results were 12 minutes with just "-version" vs. 2 seconds if you start with "-branch" before "-version".

BEFORE:

view> date ; cleartool find /vob/myvob/dir1/dir2 -follow -dir -version '(hltype(Merge, <-) || hltype(Merge, -> )) && brtype(main)' -print;date
Tue Apr 24 11:04:15 PDT 2007
/vob/myvob/dir1/dir2@@/main/71
/vob/myvob/dir1/dir2@@/main/86
/vob/myvob/dir1/dir2@@/main/87
/vob/myvob/dir1/dir2@@/main/88
/vob/myvob/dir1/dir2@@/main/89
/vob/myvob/dir1/dir2@@/main/90
/vob/myvob/dir1/dir2@@/main/91
/vob/myvob/dir1/dir2@@/main/92
/vob/myvob/dir1/dir2@@/main/93
/vob/myvob/dir1/dir2@@/main/94
/vob/myvob/dir1/dir2@@/main/95
/vob/myvob/dir1/dir2@@/main/96
Tue Apr 24 11:16:28 PDT 2007

AFTER:

view> date; cleartool find /vob/myvob/dir1/dir2 -follow -dir -branch 'brtype(main)' -version '(hltype(Merge, <-) || hltype(Merge, ->))' -print;date
Tue Apr 24 11:35:40 PDT 2007
/vob/myvob/dir1/dir2@@/main/86
/vob/myvob/dir1/dir2@@/main/87
/vob/myvob/dir1/dir2@@/main/88
/vob/myvob/dir1/dir2@@/main/89
/vob/myvob/dir1/dir2@@/main/90
/vob/myvob/dir1/dir2@@/main/91
/vob/myvob/dir1/dir2@@/main/92
/vob/myvob/dir1/dir2@@/main/93
/vob/myvob/dir1/dir2@@/main/94
/vob/myvob/dir1/dir2@@/main/95
/vob/myvob/dir1/dir2@@/main/96
/vob/myvob/dir1/dir2@@/main/71
Tue Apr 24 11:35:42 PDT 2007

### 31.     How do I - copy file versions from ClearCase using cleartool find on Windows

You can copy certain versions out of your view to the local file system using command line operations.

If the element version that you want to copy is selected by the view's config spec, then the copy can be completed using the operating system (OS) copy command.

Here is the syntax using the OS copy command:

cp <source> <destination>

However, if the version of interest is not selected by the config spec, then you will need to construct a
cleartool find syntax as the find command is not limited by the view's config spec.

Using
cleartool find will allow you to copy files that are not selected by the view you are using.

Note: The source version must be selected by its version extended pathname.

The copy operation will need to rename the version extended pathname to the original element name, because the OS copy command considers the last part of the version extended pathname to be the element's true name.

Example:

%>cp file.txt@@/main/3 /export/home/user/file.txt

Note the rename from file.txt@@/main/3 to file.txt

%>cd /export/home/user

%>ls
file.txt

For the copy to work correctly on the versions that are not selected by your view, you need to copy the files using the environment variable (EV), CLEARCASE_XPN.

To counteract the OS copy behavior of preserving the version extended pathname, you can use CLEARCASE_PN to strip the leaf name of the element version, which will capture the correct target.

The following find command example will locate the file and specific version in the VOB and copy it to your location of choice:

Example:

cleartool find . <query> -exec 'cp -p $CLEARCASE_XPN /tmp/$CLEARCASE_PN'

Refer to the IBM Rational ClearCase Command Reference Manual under the topic of query_language for details about structuring the <query>.

CAUTION: You will see unexpected results if running this find command from a snapshot view because of a known behavior difference with how snapshot view render path delivered by the CLEARCASE_XPN variable versus how dynamic views render the paths.

A snapshot view will provide a path which is will contain the snapshot view path followed by the VOB tag path followed by the actual filename and path below the VOB tag root.

A dynamic view will provide will simply show the VOB path followed by the actual filename and path below the VOB tag root.

Example:

Snapshot View Output from CLEARCASE_XPN

/export/home/snapshots/view_1/vobs/vob1/dir1/file

is returned from a snapshot view instead of...

Dynamic View Output from CLEARCASE_XPN

/vobs/vob1/dir1/file

## Utilities

### 32.     How do I – understand about changing the ownership of a VOB and its objects on Windows

How can I change or correct the user and group permissions on a VOB and its objects in a Microsoft® Windows® environment using the IBM® Rational® ClearCase® fix_prot and vob_sidwalk reprotection commands

After a hardware migration or domain migration, it is generally necessary to reprotect several objects in the VOB, if not all of them.

The VOB move procedure is documented in IBM Rational ClearCase Administrator's Guide > Moving VOBs and Relocating VOB Data.

The procedures detailed are applicable when changing hardware or joining the server to a new network.

The following article is a supplement to the information provided in the above documentation. If you have not already done so, then it is advised that you review the manual before proceeding; to verify that you understand the material and use the appropriate directions for moving VOBs in your Rational ClearCase configuration.

• fix_prot, refer to IBM Rational ClearCase Administrator's Guide > Troubleshooting > Utilities for Fixing Protection Problems as well as technote 1142606.
• vob_sidwalk, refer to IBM Rational ClearCase Command Reference, or run cleartool man vob_sidwalk from command line as well as technote 1256390.

Scenarios for using fix_prot and vob_sidwalk

These directions will ultimately repair all, but are not limited to, errors produced by the following situations:

• Deletion of a user and group from a Windows domain that owns ClearCase objects
• Creation of a VOB as a user and group identity other than the VOB administrator
• Removing groups from a VOB's group list
• Reprotecting metadata type definitions and instances
• Domain Migrations
• Hardware Migrations

Restrictions

You must have one of the following identities to run vob_sidwalk:

Command Syntax

The utilities used in this technote are located in the %RATIONALHOME%\etc\utils directory.

Note: \sidwalktest is the VOB tag in the following commands.

First use fix_prot on the VOB storage

1. Stop the ClearCase services from the ClearCase Properties applet in the Windows Control Panel:

2. Go to the %RATIONALHOME%\etc\utils directory in the command prompt.

3. Run the fix_prot utility as follows:

fix_prot -r -root -chown <new_owner> -chgrp <new_primary_group> <path to VOB storage directory>

fix_prot will remove all additional groups from the VOBs group list.
If there were additional groups in the VOBs group list, add those groups back by running protectvob (see step 5 below).

4. Restart the ClearCase services from the ClearCase applet in the control panel.

5. Add the additional groups back to the VOBs group list by running protectvob:

cleartool protectvob -add_group <groupname, groupname2, ...> <vob-storage-pname>

Then use vob_sidwalk on the VOB objects

1. Set the user variable
CLEARCASE_PRIMARY_GROUP=<clearcase_users_group>

2. Determine the user and group information for the account that will own the VOB. Log in as that user and run creds; refer to technote 1221403 for directions.

3. Run vob_sidwalk to create the dumpfile:

vob_sidwalk \sidwalktest c:\sid1

4. Edit the dumpfile, sid1, using notepad to include the new owner user and group information that is from the creds output.

5. Run the vob_sidwalk command to map the objects to the new SIDs:

vob_sidwalk -map c:\sid1 -execute \sidwalktest c:\temp\sid2

6. Run the vob_sidwalk command to remove the historical SIDs:

vob_sidwalk -delete_groups \sidwalktest c:\temp\sid3

7. Run the vob_sidwalk command to update the file system permissions:

vob_sidwalk -recover_filesystem \sidwalktest c:\temp\sid4

8. Run a describe on the VOB to verify the change:

cleartool des -l vob:\sidwalktest

9. Mount the VOB to verify access and that there are no permission related errors

Related information

### 33.     How do I - automatically remove version 0 which remains after an uncheckout

How do I automatically remove the 0 version which remains after an uncheckout command is executed while creating a new IBM® Rational® ClearCase® branch for an element?

Cause

An uncheckout operation was performed on an element leaving the new branch instance and only a 0 version on the branch.

IBM Rational does not provide any customized or user requested scripts; however, there is a trigger and script combination available on the developerWorks website in IBM Rational ClearCase: The ten best triggers under the section Remove Empty Branch.

### 34.     How do I – understand about the performance improvement in IBM® Rational® ClearCase® Version Tree Browser

For a file element with a large amount of metadata, the Windows client version tree browser had a slow response time.

Resolving the problem

As an end user of ClearCase® Version Tree, you are given the control to selectively display certain metadata via following options:

Meta Data Filter:

These metadata preferences can be set by selecting the filter options in Tools -> Options -> Meta data Filter. The preferences available are Labels, Attributes, Activities and Creation Info as shown in fig 1

fig 1

Merge Arrows:

You can control the display of Merge Arrows by using the "Merge Arrow" icon as shown in fig 2.

fig 2

or by selecting "Merge Arrow" option as shown in the fig 3 below

fig 3

Previously these options were used only to control the display, but from now on, only the selected criteria will be fetched and displayed on demand.

Say for example, "Labels" in the metadata filter options was not selected initially and now you need this information. In order to retrieve the "labels" follow the steps below:

Step 1: Go to Tools -> Options

Step 2: Select Meta Data Filter tab

Step 3: Select "Labels" check box

Step 4: Click "OK" or "Apply"

Labels will be fetched and displayed.

Similarly Activities, Attributes and Creation info can be retrieved.

In order to fetch and display Merge Arrow you can either click " Merge Arrow " icon or View options as shown in fig 1 & fig 2 respectively.

Locate Dialog: [ Tools -> Locate or Ctrl+L ]

Say you have selected to fetch few metadata and then you try to locate the version based on any of the rest of metadata. In this case, the rest of the metadata which you have selected will be fetched first and then the metadata list will be populated in locate dialog.

### 35.     How do I - use Netdump on Red Hat Linux to troubleshoot ClearCase

Where can you find information and instructions for configuring the Red Hat® Linux® crash dump utility netdump, which can be used for troubleshooting problems related to or affecting IBM® Rational® ClearCase® functionality?

In Red Hat Linux Advanced Server 2.1, Red Hat provides a crash dump facility, netdump.

Note: Since Red Hat Enterprise Linux 5 netdump is no longer supported (refer to http://kbase.redhat.com/faq/docs/DOC-4104) instead you can use kdump. Full instructions on how to set this up are provided by Red Hat on the following link: http://kbase.redhat.com/faq/docs/DOC-6039

This facility dumps memory images from the network to a centralized server; known as a netdump server and limits the size of each dump file and you can set the number of crash dumps that you want to keep around at any one time.

There are cases where this data can be very helpful in troubleshooting problems related to or affecting Rational ClearCase functionality.

For more information, such as the supported network devices, and specifics for configuring this utility read the white papers at:

All of the configuration information can be found within both white paper documents listed above.
If you require further guidance as to the setup and configuration of Netdump, you will have to contact Red Hat support.

Here is an overview of what will essentially occur to capture the dump:

1.     Force a crash while the Clearcase problem is occuring:

Turn on sysrq:
sysctl -w kernel.sysrq=1

Trigger the crash
: echo c > /proc/sysrq-trigger

Note: /proc/sysrq-trigger is typically found in the 2.6 kernel and may have also been backported to RHEL 3 kernels.

2.     System can also be forced to crash from the console by pressing: Alt-syrq-c

Here are the command keys (for quick reference):

'r'     - Turns off keyboard raw mode and sets it to XLATE.

'k'     - Secure Access Key (SAK) Kills all programs on the current virtual console. NOTE: See important comments below in SAK section.

'b'     - Will immediately reboot the system without syncing or unmounting your disks.

'c'     - Intentionally crash the system without syncing or unmounting your disks.  This is most useful if the NETDUMP client package has been installed.

'o'     - Will shut your system off (if configured and supported).

's'     - Will attempt to sync all mounted filesystems.

'u'     - Will attempt to remount all mounted filesystems read-only.

'p'     - Will dump the current registers and flags to your console.

't'     - Will dump a list of current tasks and their information to your console.

'm'     - Will dump current memory info to your console.

'0'-'9' - Sets the console log level, controlling which kernel messages will be printed to your console. ('0', for example would make it so that only emergency messages like PANICs or OOPSes would

'e'     - Send a SIGTERM to all processes, except for init.

'i'     - Send a SIGKILL to all processes, except for init.

'l'     - Send a SIGKILL to all processes, INCLUDING init. (Your system will be non-functional after this.)

'h'     - Will display help (NOTE: Any other key than those listed above will display help. but 'h' is easy to remember)

As for the vmlinux, vmlinux-debug and System.map files, review the following page:

Related information

### 36.     How do I – understand how to access Sample response files for IBM Rational ClearCase

Question

Where can I find a sample response file to install IBM Rational ClearCase?

The attached response files provide a template for installing IBM Rational ClearCase on a specific platform. To use the files below, download and modify following the instructions provided within.

Note: When installing IBM Rational ClearCase on Microsoft Windows operating systems, the service account password must be generated using the IBM Installation Manager Graphical User Interface. Additional details are stated within the window's response file.

For more information on using response files, see the IBM Installation Manager Information Center at:
http://publib.boulder.ibm.com/infocenter/install/v1r2/index.jsp

### 37.     How do I - Identify binary characters in text files

Files saved on different editors or IDE's with different encodings insert these characters into the text files. Command such as cleartool diff only support ASCII mode or UTF-8; anything else is seen by the diff tool as a non-printable characters and are automatically referred to as a binary element.

The issue is not limited to encoding; many of these issues are seen with configuration (Markup) files and many editors in an effort to "understand" the file and provide extra functionality to is, insert a BOM at the top of the file, BOM being Byte Order Mark which might also be interpreted as binary data, hence giving us the error upon trying to diff.

Solution

DISCLAIMER:
All source code and/or binaries attached to this document are referred to here as "the Program". IBM is not providing program services of any kind for the Program. IBM is providing the Program on an "AS IS" basis without warranty of any kind. IBM WILL NOT BE LIABLE FOR ANY ACTUAL, DIRECT, SPECIAL, INCIDENTAL, OR INDIRECT DAMAGES OR FOR ANY ECONOMIC CONSEQUENTIAL DAMAGES (INCLUDING LOST PROFITS OR SAVINGS), EVEN IF IBM, OR ITS RESELLER, HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

If you have a Java™ JDK installed you can compile the Java class below; otherwise, download the precompiled class file attached and skip to step 3).

1. Copy and paste the Java code below into a text file named TestAsciii.java in your TEMP directory.

import java.io.*;
import java.nio.ByteBuffer;
import java.nio.CharBuffer;
import java.nio.charset.Charset;
import java.nio.charset.CharsetDecoder;
import java.nio.charset.CharacterCodingException;

public class TestAscii {

public static void main (String args[])
throws Exception {
// this String throws an Exception if it contains non-ascii characters

byte bytearray []  = test.getBytes();
System.out.println("Test string : " + test);

CharsetDecoder d = Charset.forName("US-ASCII").newDecoder();
try {
CharBuffer r = d.decode(ByteBuffer.wrap(bytearray));
r.toString();
}
catch(CharacterCodingException e) {
// interrupt the processing
throw new Exception(e);
}
System.out.println("Ok, it's ASCII only!");
}
}

2. Compile the following Java program using javac as follows:

C:\TEMP> javac TestAscii.java

3. Obtain the text file with the problem (diffing or merging) and rename the file to infile.txt.

4. Run the Java program as follows:

C:\TEMP> java -cp . TestAscii

If the file has Binary data, it will display the line where the binary characters are contained followed by an the exception trace.

Example:

1. Copy the attached class file and text file to a temp directory.

2. Open a command prompt and display the contents of the attached text file:

C:\temp>type infile.txt
hello this is a text file
???????????????hello this is a text file
??
ˇ»

2. Run the command from step 3.

Non-text output:

C:\temp>java -cp . TestAscii
Test string :  h e l l o   t h i s   i s   a   t e x t   f i l e
Exception in thread "main" java.lang.Exception: java.nio.charset.MalformedInputException:
Input length = 1
at TestAscii.main(TestAscii.java:34)
Caused by: java.nio.charset.MalformedInputException: Input length = 1
at java.nio.charset.CoderResult.throwException(Unknown Source)
at java.nio.charset.CharsetDecoder.decode(Unknown Source)
at TestAscii.main(TestAscii.java:28)

C:\temp>type infile.txt
hello this is a text file
???????????????hello this is a text file
??
ˇ»

Text-only output:

C:\temp>java -cp . TestAscii
Test string : this is a text file
Ok, it's ASCII only!

### 38.     How do I - handle binary files in ClearCase

Method to manage binary files that are stored in an IBM® Rational® ClearCase® VOB in either a base ClearCase or UCM environment.

Binary files are handled in UCM the same way they are handled in base ClearCase; they cannot be merged.

ClearCase can only merge text files; therefore a different strategy must be deployed in order to manage change related to binary content.

In order to effectively manage binary files in ClearCase, new element types must be defined to handle these file types:

·         2002.05.00 and 2003.06.00: Configured to be never considered for merging.

Note: The following instructions are taken from the point of view of the Microsoft® Windows® operating system. The steps may differ on UNIX® and Linux®, but the concepts apply exactly.

Note: The element type can be created from command line or the GUI.

1.     Reuse an existing element type or Create a new one from the command line or GUI. See step 2 if the element type already exists.

Review the ClearCase Reference Guide on the topic of mkeltype (
cleartool man mkeltype) for more details.

GUI example > Create:

·         Open Type Explorer GUI for the VOB (Start > Programs > Rational ClearCase> Type Explorer)

·         Select the VOB where binary files exist.

·         Open the element type folder

·         Right-click and create a new element type.

·         Give the element type a name (for example NEVER_MERGE or COPY or any name of your choosing).

·         Click OK

Example: NEVER_MERGE

Example: COPY

2.     From the Type Manager tab in the element type's Properties dialog box, enable the option to

Never consider elements of this type for merging

or

Always copy elements of this type (ClearCase 7.0 or later)

3.     For the binary elements that already exist in the VOB, use cleartool chtype to change these types to the new element type.

Review the ClearCase Reference Guide on the topic of chtype (
cleartool man chtype) for more details.

4.     For the binary files that do not yet reside in the VOB, the magic file can be edited to call the new element type for elements with a certain extension. Upon element creation these files will use the new type you have defined to manage those file elements.

Review the ClearCase Reference Guide on the topic of cc.magic, default.magic (
cleartool man cc.magic) for more details.

Instructions for replicated VOBs prior to version 7.0

The same steps are required as above; however, the element types need to be created from the command line in a replicated environment prior to 7.0.

In ClearCase 7.0 and later, the GUI can now be used to create element types in a replicated VOB.

Example:

Never Merge Example:

M:\view\vob>cleartool mkeltype -supertype file -mergetype never -nc FILE_NEVER_MERGE
Created element type "FILE_NEVER_MERGE".

Copy Example:

M:\view\vob>cleartool mkeltype -supertype compressed_file -mergetype copy -nc COMPRESSED_FILE_COPY_MERGE
Created element type "COMPRESSED_FILE_COPY_MERGE".

The definitions for trivial and manual merging

Trivial: The base and the destination versions of the element are the same.
This means the element can simply be copied from the source to the destination view. A trivial merge is automatically determined by merge or findmerge and thus will be taken care of for you.

Manual: The source and destination versions of the element contain one or more conflicts that you must resolve. A manual merge thus requires that you:

1.     Check out the destination version.

2.     Copy the data from the source version to the destination version.

3.     Checkin the destination version.

Manually draw the merge arrow in a version tree GUI or you can run the 'cleartool merge' command with a -ndata switch to manually establish the merge arrow between the source and destination versions.

### 39.     How do I - integrate Rational Manual Tester project with Clear Case

When moving the Rational Manual Tester project from the network drive with UNC path to the dynamic view/local drive with absolute path, the keyword lib link in the Rational Manual Tester's contentResource file is broken, so the keyword created and checked in by one user can not be used by another user.

Rational Manual Tester does not differentiate whether it is network drive or local drive, the type of drive is being configured before using Rational Manual Tester. Rational Manual Tester uses the same path -- for referring to keywords -- that was provided by the user to create / open the project.
For example, I have a project on the network folder @ \\computer\share\project; and, it has a script called untitled2.rmt.

If I open the project on the network using UNC path -- like \\computer\share\project and create a keyword called 'keyword_unc', drag and drop it onto the above script, the path will be stored as

<interactionFragments xsi:type="Common_Behavior_Interactions:BVRExecutionOccurrence" id="CC92D095C975CD849A4B379562BB11DD" otherBehavior="CC92D095C975CD849A4B379062BB11DD"/>

<interactionFragments xsi:type="Common_Behavior_Interactions:BVRExecutionOccurrence" id="D6D29EDA76C84ABE1AA42580832411DE" name="\\9.124.23.99\RMT_Share\Project2\Libraries\keyword_UNC_101e3f40-ebe8-4f28-bb6d-ced9b86fa3ed.kwd (keyword_UNC)">

<otherBehavior href="../Libraries/keyword_UNC_101e3f40-ebe8-4f28-bb6d-ced9b86fa3ed.kwd#D6D29EDA76C84ABE05EB1F94832411DE"/>

</interactionFragments>

If I map the project folder onto a drive letter -- say Y: -- and open the project using the path Y:\project and create a keyword called 'keyword_mapped', drag and drop it onto the same script, the path will be stored as

<interactionFragments xsi:type="Common_Behavior_Interactions:BVRExecutionOccurrence" id="D6D29EDA76C84ABE18A39A95832411DE" otherBehavior="D6D29EDA76C84ABE18A39A90832411DE"/>

<interactionFragments xsi:type="Common_Behavior_Interactions:BVRExecutionOccurrence" id="D6D29EDA76C84ABEAE752E30832411DE" name="Y:\Project2\Libraries\keyword_mapped_854b02f4-3f28-47e4-ae0c-5c0c6465f0e6.kwd (keyword_mapped)">

<otherBehavior href="../Libraries/keyword_mapped_854b02f4-3f28-47e4-ae0c-5c0c6465f0e6.kwd#D6D29EDA76C84ABE9DE649F4832411DE"/>

</interactionFragments>

Although it is same project, notice the difference -- it all depends on how one opens the project.

So one solutions is:

Have all the users mapping their projects to the same drive letter if using dynamic view, and keep all the dynamic views the same name.

## Config specs

### 40.     How do I - change the default config spec prior to view creation

The view creation operation uses a default config spec as follows:

element * CHECKEDOUT

element * /main/LATEST

This information is stored on every client in the root of the ClearCase installation directory in a file named default_config_spec:

Microsoft® Windows®:
C:\Program Files\Rational\ClearCase

UNIX® and Linux®: /opt/rational/clearcase

If your goal is to create a view whose default config spec is something other than /main/LATEST, you can modify the default_config_spec file on each client that requires a different default config spec.

The following example (run from UNIX) illustrates the affects of making a change to the default_config_spec file:

prompt% cat default_config_spec
element * CHECKEDOUT
element * /main/bugs/LATEST
element * /main/LATEST -mkbranch bugs

prompt% cleartool mkview -tag new_config ~/store/new_config.vws
Created view.
Host-local path: hostname:/export/home/user/store/new_config.vws
Global path: /net/hostname/export/home/user/store/new_config.vws
It has the following rights:
User : user : rwx
Group: group : rwx
Other: : rwx

prompt% cleartool setview new_config

prompt% cleartool catcs
element * CHECKEDOUT
element * /main/bugs/LATEST
element * /main/LATEST -mkbranch bugs

### 41.     How do I - detect lines with 8000 or more characters

The IBM® Rational® ClearCase® text element type manager has an 8000 character per line limitation when performing comparison or merges. This technote provides a method to help detect lines in a file element that exceed the 8000 character limitation.

Solution

The following Perl script is an example to help detect lines that have 8000 or more characters.

1.     Copy the code below into a text file (for example 8000.pl)

2.     Open a command prompt, set into a view, mount and cd in the VOB you wish to examine.

3.     Use ccperl to run the script (example ccperl 8000.pl)

EXAMPLE:

WITHIN A DIRECTORY

M:\dynamic_view\my_test_vob\promo>ccperl 8000.pl
------------ Line(s) Over 8000 Bytes -----------
.\test.txt : Line# 1   Bytes 8580

OUTSIDE A DIRECTORY

M:\dynamic_view\my_test_vob>ccperl 8000.pl promo
------------ Line(s) Over 8000 Bytes -----------
promo\test.txt : Line# 1   Bytes 8580

CODE

#
# Usage: ccperl this-file-name.pl [directory name]
# Run this script in a View/VOB context.
#

# Obtain a directory name from argument
if( $#ARGV < 0 ) {$dirname = ".";
}else {
$dirname = shift( @ARGV ); } opendir DIR,$dirname or die "Error: Cannot open dir[$dirname]\n"; print "------------ Line(s) Over 8000 Bytes -----------\n"; # Check all files on the directory while($fname = readdir DIR ) {

$fname =$dirname . "\\" . $fname; #Skip if the file is a binary file or another directory if( -B$fname || -d $fname ) { next; } #Skip unless the file is text element$result = cleartool desc -fmt %[type]p $fname; if($result ne "text_file" && $result ne "compressed_text_file" ) { next; } #Check the number of characters open FD,$fname or next;
while( <FD> ) {
$len = (length$_) - 1;
if( $len >= 8000 ) { #Report the detecte line info print "$fname : Line# $. Bytes$len\n";
}
}
}

### 42.     How do I - view a single version and still view the LATEST version of all others

To view a specific version of a file while still viewing the LATEST version of all other element, create a config spec rule using the -file (for files) or -dir (for directories) option as follows:

Example:

element * CHECKEDOUT
element -file test_file.txt/main/23
element * /main/LATEST

This configuration will display version 23 on the main branch of file test_file.txt and display the latest versions of all other files and directories in that VOB.

Example:

element * CHECKEDOUT
element -dir dir1/main/23
element * /main/LATEST

This configuration will display version 23 on the main branch of directory dir1 and display the latest versions of all other files and directories in that VOB.

Note: The latest version of the elements within dir1 will be displayed (not version 23).

## Registry

### 43.     How do I – understand about rgy_getuuid_by_uuid failed errors

At times these entries may be seen in the ClearCase logs:

10/18/99 11:55:37 view_server(13967): Error: Operation "rgy_getuuid_by_uuid" failed
10/18/99 15:22:48 view_server(13967): Error: Operation "rgy_getuuid_by_uuid" failed

The
rgy_getuuid_by_uuid error indicates that ClearCase is trying to look something up in the ClearCase registry by its UUID and is failing, finding no entry with that UUID.

This type of error could originate from either a view or a VOB since both use a UUID identification object. The errors above correspond from a view_server process and therefore relate to a view. If the errors correspond to a VOB, it is likely that the output would look similar to the following:

cleartool: Error: Unable to find replica in registry for VOB with object ID:"9250ab61.6f04465d.b3f4.d7:a4:a1:74:0c:85"
cleartool: Error: Unable to locate versioned object base with object id: "9250ab61.6f04465d.b3f4.d7:a4:a1:74:0c:85".

Cause

In this case, the error is likely the result of some confusion with the VOB hyperlink to an AdminVOB.

Diagnosing the problem

There is no means within the error message of denoting what clients are causing the errors. Hence, you have to strategically back track from the error message to the problem system. One particular strategy that can be helpful is this:

1.     Within the view_log, of the view server host machine, note the view_server pid(s) where the rgy error occurred (for example: 10/18/99 11:55:37 view_server(13967): Error: Operation "rgy_getuuid_by_uuid" failed
the pid would be 13967)

2.     On the view server machine still, find the view's uuid by issuing 'ps -ef | grep <view svr pid>'.
If the view server is still alive, it should return the pertinent data containing the view's uuid (ie.
ccadmin   1362  2071  0 Jun04 ?        00:00:00 view_server /viewstore/ccadmin_view.vws -u 10a9b6cb.884111da.8767.00:b0:d0:94:71:23 -S12:16,udp:17,tcp )

3.     From the view's uuid, one can obtain the last user and machine that accessed the view by issuing
'ct lsview -properties -uuid <view uuid>

Example:

Last accessed 04-Aug-06.10:41:33 by root.root@my-host.my-company.com
Group: domainx-com/cc_users : rwx (all)

Based on the machine information one has acquired from #3, the succeeding step is to access that machine and read the contents of the /etc/mnttab file and grep for the removed VOB, 'cat /etc/mnttab | grep <VOBtag>'. if the VOB tag and/or vob storage is found in the /etc/mnttab file, then an issue of 'ct umount <VOB tag>' may resolve the problem. On Linux you will need to search in the /etc/mtab file.

Resolving the problem

If the errors originate from the view_server and or log, check to see if the error is reporting on the same UUID. If so there is probably one view that has been improperly deleted but still has checkouts in some of the VOBs.

It is also good to note that such an error, specifically in the view_log of the view server host machine, but not the vob_log of the VOB server host machine, can be indicative of a client having a mounted VOB that has since been removed (from the registry and its storage). This causes the client system to continue to try and access the now removed VOB, resulting in rgy_getuuid_by_uuid errors. The resolution to this problem is to simply issue a cleartool umount <VOB tag> of the removed VOB on the problem client system.

Run the rmview -uuid command to remove all references to this view in all VOBs on the server (review to technote 1122515 for more details):

%> cleartool rmview -avobs -uuid 23dd562d.8ebf11d6.a7d9.00:01:80:f0:f4:92
Removed references to view "23dd562d.8ebf11d6.a7d9.00:01:80:f0:f4:92" from VOB "/vobs/admin".
Removed references to view "23dd562d.8ebf11d6.a7d9.00:01:80:f0:f4:92" from VOB "/vobs/local".
Removed references to view "23dd562d.8ebf11d6.a7d9.00:01:80:f0:f4:92" from VOB "/vobs/pvob".

If the errors in the logs report multiple UUIDs, then check all of the VOBs to see if there are multiple deleted views. Look for the views listed in the "VOB holds objects from the following views" section in the output of the describe -long vob:<vob> command:

% > cleartool describe -long vob:/vobs/grouptest
versioned object base "/vobs/grouptest"
created 27-Jun-02.05:27:40 by John Doe (jdoe.grouptest2@host1)
VOB family feature level: 2
VOB storage host:pathname "host1:/vobstore/grouptest.vbs"
VOB storage global pathname "/net/host1/vobstore/grouptest.vbs"
database schema version: 54
VOB ownership:
owner jdoe
group grouptest2
group sybase
group grouptest1
VOB holds objects from the following views:
anemone:/my/storage/mollyview.vws [uuid d79fd5ce.e83911d5.b275.00:01:80:f0:f4:92]
anemone:/my/storage/timb.vws [uuid 23dd562d.8ebf11d6.a7d9.00:01:80:f0:f4:92]

Attributes:
FeatureLevel = 2

It is likely that there will be references to these views in the VOBs.

Before removing each view, ensure that it is not currently registered by running the
cleartool lsvob and lsview commands:

% > cleartool lsview -uuid 23dd562d.8ebf11d6.a7d9.00:01:80:f0:f4:92
cleartool: Error: No matching entries found for uuid 23dd562d.8ebf11d6.a7d9.00:01:80:f0:f4:92.

% > cleartool lsvob -uuid 23dd562d.8ebf11d6.a7d9.00:01:80:f0:f4:92
cleartool: Error: No matching entries found for uuid 23dd562d.8ebf11d6.a7d9.00:01:80:f0:f4:92.

Note: Similar errors may be seen if a view or VOB was created in a different region. Be sure to run lsview or lsvob in all the regions using the -region option for each region in your environment.

If the UUID displays an entry in either registry table, then do not remove it.

Instead, run the rgy_check -views or rgy_check -vobs command depending on which registry table it turned up in and then repair the problems it reports.

Note:
If it is not possible to identify where the original view was located (perhaps it was created on one of many client machines not identified in any error message even running lsvob -long), then the only option is to wait until someone states that one of their views is not working. This issue can then be investigated properly. Meanwhile the error message in the vob_server logs will not cause any harm and can be ignored.

Review the IBM Rational ClearCase Command Reference on the topic of rgy_check (

## ncaexported

### 44.     How do I – set up an ncaexport

1.     In the /etc/exports.mvfs file on the server, add the view/VOB combination as follows:

/view/test_vu/vobs/test_vob -rw

Note: For the VIEW and VOB being exported. It is best if the VIEW and VOB are hosted on the same server.

2.     Update the View and VOB tags to be exported as follows:

cleartool mktag -view -replace -ncaexported -tag test_vu <view_storage path>

cleartool mktag -vob -replace -ncaexported -tag /vobs/test_vob <vob_storage path>

3.     Export that view/VOB combo by running:

/opt/rational/clearcase/etc/export_mvfs -a

4.     On the client side as root configure the host as follows:

Example:

mkdir /tmp/ncaexport

mount <hostname>:/view/test_vu/vobs/test_vob /tmp/ncaexport

Then cd into /tmp/ncaexport and you'll see the data from the View/VOB.

## Lost+found directory

### 45.     How do I - use of pattern matching to remove objects from the lost+found directory

The cleartool interactive shell combined with pattern matching can be used to remove multiple elements at once from the lost+found directory of a VOB.

In the event that the cleartool interactive shell pattern matching does not remove all elements in lost+found, a command script for Microsoft® Windows® or one for UNIX® and Linux® is also included.

IMPORTANT: Before following these instructions, you should verify the relevance of the files in the lost+found directory. If there is a chance that these files should not be deleted, do not follow these instructions. More information on the lost+found directory including why elements are moved into lost+found can be found in the IBM Rational ClearCase Administrator's Guide on the section titled The lost+found Directory in the VOB Administration Chapter.

From within a ClearCase view, cd into the lost+found directory, start the cleartool interactive shell, and issue the rmelem command:

Z:\VOB1\lost+found>cleartool
cleartool> rmelem *.*

CAUTION! This will destroy the element, all its branches and versions, including all data, meta-data and history, and will remove the element from all directory versions that now contain it.  Once you destroy the element, there will be no way to restore it to its current state. If you want to preserve the element, but remove references to it from future directory versions, use the "rmname" command.

Element "nameapp.c.e83edfb9dfa042db90b83d4417fdec5c" has 1 branches, 2 versions, and is entered in 1 directory versions.
Destroy element?  [no] yes
Removed element "nameapp.c.e83edfb9dfa042db90b83d4417fdec5c".

cleartool>

Note: Use the -force switch to suppress being prompted with "Destroy element?", for example:
cleartool> rmelem -force *.*

Deleting multiple Directory Levels

If there are directories stored in the lost+found directory that should be removed during this procedure, then you use either of the following to remove all its contents:

1.     Run rmelem multiple times:

·         After the first iteration, all elements that were in a sub-directory under lost+found get moved to the root of lost+found.

·         The subsequent iteration of rmelem will remove the elements that were moved to the root of lost+found.

2.     Use the find command with the -depth option:

Z:\VOB1\lost+found>cleartool

cleartool> find lost+found -depth -exec "cleartool rmelem -f "%CLEARCASE_PN%"'

Note: Use of cleartool interactive mode allows the use of single quotes for the -exec parameter.

3.     Run rmelem within a for loop on Windows.

Within a ClearCase view, cd to the lost+found directory and issue the following "for" loop:

Z:\VOB1\lost+found>for %V in (*.*) do cleartool rmelem -force "%V"

Note: The quotes are necessary to expand file names that have spaces.

4.     Run rmelem within a for loop on UNIX or Linux.

Within a ClearCase view, cd to the lost+found directory and issue the following:

·         Korn shell:
for file in ls    <enter>
> do   <enter>
> cleartool rmelem -force $file > done <enter> PS: x = file · C-Shell: #foreach file (ls) ?cleartool rmelem$file
?end

### 46.     How do I - remove checked out elements from lost+found

When working in a ClearCase VOB, if a directory element is removed that still contains elements with checked out versions, then those checkouts are moved to the lost+found directory:

• Remove directory that contains at least one checked out element:

%>cleartool rmelem dir2
cleartool: Warning: Object "film.txt" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as
cleartool: Warning: Object "mydoc2.txt" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as "mydoc2.txt.bff49e6f10c548b088465a966715e0df".
Removed element "dir2".
• List contents of lost+found shows:

view\vob\lost+found>cleartool ls
mydoc2.txt.bff49e6f10c548b088465a966715e0df@@\main\1     Rule: \main\LATEST
• Attempts to remove the element with checkedout versions fail with:

cleartool: Error: Can't delete element with checked out versions.
cleartool: Error: Unable to remove element "film.txt.d541d0371cb24d37ad741c7fa9b7e83a".
• Listing checkouts in the lost+found shows:

view\vob\lost+found>cleartool lsco

This is expected behavior.

In ClearCase, elements with checkedout versions cannot be removed; hence; the checkouts must be cancelled or checked in before the element can be removed.

The checkout can be cancelled successfully from the view that it originated in using cleartool unco, but if that view is no longer accessible, then the attempt to undo the checkout will fail with:

cleartool: Error: No branch of element is checked out to view
Ibm-d15f3483123:C:\ClearCase_Storage\views\ap_vu.vws".
cleartool: Error: Unable to find checked out version for

Solution

The checkout must be cancelled before the element can be removed from the lost+found directory.

Note: If the view the checkout originated in still exist, then use that and run cleartool unco.

To cancel the checkout when the original view is not availalble:

Describe the VOB to get the view's uuid where the checkout originated in:

view\vob\lost+found>cleartool describe -long vob:\1vob
versioned object base "\1vob"
created 2007-04-09T18:06:35-04 by jdoe.grp1@HOST1
VOB family feature level: 5
VOB storage host:pathname "HOST1:C:\ClearCase_Storage\vobs\1vob.vbs"
VOB storage global pathname "\\HOST1\share\vobs\1vob.vbs"
database schema version: 54
modification by remote privileged user: allowed
VOB ownership:
owner DOM1\jdoe
group DOM1\grp1
VOB holds objects from the following views:
Attributes:
FeatureLevel = 5

Remove the checkout reference:

view\vob\lost+found>cleartool rmview -uuid 89d34640.f6e54e03.9c16.d3:3c:23:ce:2b:5b
Removed references to view "HOST2:C:\ClearCase_Storage\views\admin_vu" from VOB "\1vob".

Listing the checkouts in the lost+found will no longer return any output.

Remove the element from the lost+found directory:

## Data exchange with IBM Rational

### 47.     How do I - exchange data with IBM Rational Support

The following methods are available for submitting files to IBM support:

 Sending files to Rational Support

When it is necessary to send files to Rational support, there are numerous methods available for sending the data to support. All files delivered electronically to IBM must be in a compressed or packed format.

Using the following naming convention allows the support tools to move your file automatically to the proper directories and update the PMR to indicate that the file is available: xxxxx.bbb.ccc.yyy.zzz

Note:
It is common for IBM support to refer to a PMR number as the entire combination of the PMR, Branch and IBM Country codes, as that combination reflects a unique identifier.

Example: 34143.055.724.server_log_3.zip (pmr_#.branch_office_#.country_code.file_name.file_type)

 Field Explanation Sample xxxxx PMR Number 34143 bbb Branch Office 055 ccc 724 yyy A short description for the file server_log_3 zzz File type zip

 Electrontic Service Request (ESR)

You can attach files to your Problem Management Record (PMR) . Electronic Service Request (ESR) allows customer to submit and manage Problem Management Records (PMRs) on demand: 24 hours a day, 7 days a week, 365 days a year.

Note: ESR can also be linked to the IBM Support Assistant (ISA) and IBM Software Support Toolbar.

 E-Mail

If the zip file created is less than 30 MB, you can e-mail it to IBM Rational Software by performing the following steps:

Note: Depending on your internet connection and e-mail server, allowable attachment file may be significantly less that the 30 MB limit. When in doubt you might simply use the FTP steps to ensure timely delivery of your files.

1.     Create an email message addressed to "sw_support@us.ibm.com"

2.     If you already have a PMR number, please put the syntax PMR##xxxxxxx in the Subject line (where "xxxxxxx" is the PMR ID assigned to your ticket). If you do not already have a PMR number, put the product name "ClearQuest" in the Subject string.

3.     In the body of the message, put a brief description of the problem symptoms and describe the databases you have sent in.

4.     Attach the zip file to the message.

 FTP

If the zip file is larger than 30 Mb, do not use e-mail to send it. Send it using the IBM FTP site. Detailed instructions can be found at the IBM Enhanced Customer Data Repository (ECuRep) site.

Note:
The ECuRep FTP site is the replacement for the old testcase FTP site.

1.     If you do not already have an open PMR, contact Rational Support to create one, or use ESR.

2.     From a command prompt or terminal window, FTP to the ftp.emea.ibm.com site.
ftp ftp.emea.ibm.com

5.     Change your directory to the "toibm" directory by entering the following command:
cd toibm

6.     Change your directory to the "rational" directory by entering the following command:
cd rational

7.     Enter the command binary to enable binary mode for the ftp session

8.     Enter the command put xxxxx.bbb.ccc.yyy.yyy to upload the data to the server

9.     Enter the command quit to end your FTP session

10.  Once the file has been placed on the ftp site, notify Rational Support that you have sent the file: send e-mail to sw_support@us.ibm.com, with the PMR number in the Subject line; be sure to mention the precise name of the file you have sent, and the directory that it was put into

 Receiving files from Rational Support

Occasionally IBM Rational Customer Support needs to make files available for customer download. In the event that you need to pull a file from the IBM FTP site, use the following instructions and the exact filename name provided by your IBM support rep:

1.     From a command prompt or terminal window, FTP to the ftp.emea.ibm.com site.
ftp ftp.emea.ibm.com

4.     Change your directory to the "fromibm" directory by entering the following command:
cd fromibm/rational

5.     Enter the command binary to enable binary mode for the ftp session.

6.     Enter the command get file.name to download the data from the server, where file.name is the exact file name communicated to you by your IBM support representive.
Note: You must provide this because the
fromibm/rational folder is "blind" - that is, you cannot list the files contained in that directory.

Enter the command quit to end your FTP session

### 48.     How do I – understand Knowledge Collection: Tracing for IBM Rational ClearCase family products

This knowledge collection is intended to provide a single listing of resources that contain information about the various tracing utilities and procedures used to troubleshoot issues encountered when using the ClearCase Family of products.

See Change History for most recent updates to this Knowledge Collection.

3rd Party Integrations

Technote 1125729 Enabling SCC trace operations with ClearCase

Refer to The Rational ClearCase integration with Microsoft Office under the topic of About Tracing

Technote 1234118 How to setup debug tracing for the ClearCase Remote Client

Technote 1256967 Trace CCWeb client operations on Windows using Internet Explorer

Technote 1266287 How to setup debug tracing for the ClearCase SCM Adapter using Rational tools

Technote 1224917 Level 4 tracing crashes ClearCase Web or CCRC

Installation

Technote 1358626 How to enable debugging for ClearCase and ClearQuest installs using Installation Manager

Clearmake and Omake

Technote 1149150 Tracing IBM Rational ClearCase build tools

MultiSite

Technote 1151757 Tracing ClearCase MultiSite

Technote 1118202 Debugging the MultiSite sync_receive.bat script

Refer to the ClearCase MultiSite Administrators guide on the following topics which contain related trace information:

MVFS

Rational Product Integrations

Technote 1132466 Enable debug mode or set up tracing in WSAD to troubleshoot ClearCase integration issues

Technote 1289545 Location of the cqcc_output.log file when using the ClearCase and ClearQuest V2 with central caching enabled

Triggers

UCM and CQ Integration

Technote 1125294 Setting up tracing with the ClearCase and ClearQuest UCM integration on Windows

Technote 1127287 Tracing the UCM integration with ClearQuest on UNIX or Linux

This website is published "as is". There is no warranty of any kind (express or implied) as to the operation of our site, the accuracy of the information or the services or products referred to on it. All warranties are excluded as far as permitted at law. Neither we nor any third party will be liable for any losses or damage that may result from use of the website or as a consequence of any inaccuracies in, or any omissions from, the information which it contains.