Home

How do I

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 Views – “How do I” covers: (Last updated  11-Nov-09)

·                Generaldifference snapshot dynamic, view root, etc...

·                Ownership – change of, etc...

·                Storage – renaming, regenerating, restoration, etc...

·                Environment – shells, removing –uuid, xclearcase, . (dot) files, copying files, msdostext_mode, lsview –age, etc...

·                Config Spec – understanding, default configuration, etc...

·                Snapshot views – read only attribute, view root, regeneration, etc...

·                View private – removing unreferenced, lsprivate issues, etc...

·                Problems and Issues – references that no longer exist, could not copy data, etc...

 

Table of Contents

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

Table of Contents. 1

General. 3

1.      How do I – understand the difference between Snapshot and Dynamic Views. 3

2.      How do I – understand why a View occasionally appears twice in the root of the MVFS drive on Windows. 4

3.      How do I – understand about the "Last Accessed" time stamp in cleartool lsview output  4

4.      How do I – understand what files are copied when running the tar command to copy files in a view    5

Ownership. 5

5.      How do I - change the ownership of a view on UNIX and Linux.. 5

Storage. 9

6.      How do I - run du -sk in a ClearCase view reports wrong size on Linux.. 9

7.      How do I – understand the Error: view_server died on startup; marking it as down   9

8.      How do I – understand the issue that registered view storage location created with a non global pathname cannot be used with dynamic views. 10

9.      How do I – regenerate or replacing view storage files. 11

10.         How do I - rename a ClearCase View... 12

11.         How do I - restore a view-private file from backup.. 12

12.         How do I - locate view private files in the storage directory.. 13

13.         How do I – understand the error Creating a new view in a view storage directory   14

14.         How do I – understand about dot files in the view storage.. 15

15.         How do I – understand about the view_db.state file.. 16

Environment. 16

16.         How do I - Prevent dynamic view sharing on Windows. 16

17.         How do I – resolve the setting into a view from a shell script does not process the remaining commands in the script issue.. 17

18.         How do I - get around the issue of cleartool setview –exec spawning a new shell 18

19.         How do I - run xclearcase at setview time.. 18

20.         How do I – understand about the .view file.. 18

21.         How do I – understand about View Profiles. 20

22.         How do I – understand about the .specdev file in /view directory.. 28

23.         How do I – understand about the Active flag for dynamic and shapshot views. 28

24.         How do I - configure a time-out session for idle views. 29

25.         How do I - copy all view private files and Derived objects between views. 30

26.         How do I - copy file versions from ClearCase using cleartool find on UNIX or Linux   32

27.         How do I – understand text modes (msdostext_mode). 33

28.         How do I – understand the supplement to the Command Reference Guide about cleartool lsview -age   35

29.         How do I – understand about the view_db.state file.. 35

30.         How do I – understand the “Too many open files error in view_log” issue.. 36

Config specs. 36

31.         How do I - prevent other users from modifying my view's config spec on UNIX and Linux   36

32.         How do I - change the default config spec prior to view creation.. 36

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

34.         How do I – understand the .compiled_spec and config_spec. 37

35.         How do I - hide an element in a view... 38

36.         How do I - exclude elements from a view... 38

37.         How do I - exclude branches from a view by using config spec rules. 39

38.         How do I - create a config spec to display files with a particular extension.. 39

39.         How do I – understand about the limits of the config spec editor. 40

Snapshot views. 40

40.         How do I – understand about .unloaded snapshot view files. 40

41.         How do I - create a snapshot view from Windows stored on a ClearCase UNIX server using CCFS   41

42.         How do I - remove the read-only attribute from all files loaded in a snapshot view    42

43.         How do I - Identify the snapshot view root location.. 43

44.         How do I - relocate the workspace of a snapshot view... 45

45.         How do I - regenerate the view.dat file in a ClearCase snapshot view... 46

46.         How do I - loaded but missing error after updating a snapshot view... 47

47.         How do I – understand how ClearCase idenfifies hijacked files. 48

48.         How do I – understand about snapshot views having a view root and a view storage directory   49

49.         How do I – understand the operation view_frz_ok_to_set_spec failed: Permission denied issue   49

50.         How do I – understand why snapshot views are showing all files as hijacked after moving view to new server. 50

View private. 51

51.         How do I – deal with <DIR..> names in lsprivate output. 51

52.         How do I - remove unreferenced view private files. 51

53.         How do I – understand the unable to delete a view private file issue.. 51

54.         How do I – understand why a UNIX ls command not reporting elements in view    53

55.         How do I - restore a view-private file from backup.. 53

Problems and Issues. 54

56.         How do I – understand that running du -sk in a ClearCase view reports wrong size on Linux   54

57.         How do I – understand that removing a view may cause ClearCase Explorer to crash with a memory reference error or an error "The parameter is incorrect". 54

58.         How do I – understand the issue “Unable to start ClearCase which is reporting error: trouble mounting the view root”. 55

59.         How do I – understand the “rgy_check: Error: Two View objects have the same pathname on a server” issue.. 55

60.         How do I – understand that “Adjusting the MVFS cache size when ClearCase is running may cause a kernel panic”. 56

61.         How do I - regenerate the view.dat file.. 57

62.         How do I - regenerating or replacing view storage files. 58

63.         How do I - remove checked-out references of a view from a VOB.. 58

64.         How do I – understand what to do when cleartool rmview -uuid does not remove view references  60

65.         How do I – understand the trouble removing view references from a replicated VOB using rmview -uuid -vob command.. 61

66.         How do I – understand about running recoverview when referenced checkouts still exist in a VOB even after running cleartool rmview -uuid.. 62

67.         How do I – Remove checkedout references from a view that no longer exists. 62

68.         How do I – resolve operation "view_ws_is_ws_view" failed: view storage directory or control files unavailable.. 64

69.         How do I – understand the checked out version, but could not copy data - permission denied issue   65

70.         How do I – understand the dross-device link error during view creation issue.. 66

71.         How do I – recover from a setwork operation failed in view error after VOBs moved to a new server  66

72.         How do I – deal with the error: ./identity/uid is not set-id.. 67

73.         How do I – understand the accessing non-VOB files outside of MVFS from a view extended path is not supported issue.. 67

74.         How do I – understand why you cannot copy ClearCase version in snapshot view using version extended path.. 68

75.         How do I – understand why the linker generates corrupt files in a ClearCase dynamic view    69

 

General

1.   How do I – understand the difference between Snapshot and Dynamic Views

The differences between Snapshot and Dynamic Views are the following:

Dynamic Views:

 

Snapshot Views:

Uses ClearCase File Server (CCFS)

2.   How do I – understand why a View occasionally appears twice in the root of the MVFS drive on Windows

When using IBM® Rational® ClearCase® on Microsoft® Windows®, the view appears twice in the root of the MVFS drive, once as view_name and once as view_name@@.

 

The @@ views are an artifact of certain MVFS operations such as

·         Merges

·         A describe of an element version not selected by the view

·         Showing the properties of an unselected element version in the Version Tree Browser


Note: The operations are not limited to the above list.

The viewname@@ entry appears in the MVFS drive after these operations and disappears after about 5 minutes.

These entries are completely harmless; however, be aware that you should not perform work within this context, and do not attempt to remove them manually.

3.   How do I – understand about the "Last Accessed" time stamp in cleartool lsview output

What specific actions update the "Last Accessed" time stamp that is reported when running an IBM® Rational® ClearCase® lsview (with -age, -prop or -full ) command?

 

 

It may appear when observing the Last Accessed output produced by cleartool lsview that not all access times are being recorded which is indeed the case.

Actions such as checkin, checkout, cd in to a view, set to a view are not considered by the ClearCase mechanism to be an access of the view.

Only the following actions are recorded:

Therefore if you intend to use the Last Access output in a script or some kind of filter you need to consider the above fact.

Change request (RFE) RATLC00700595 has been submitted to allow the cleartool lsview -age command to show last time you change directory into view.

 

Answer

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

4.   How do I – understand what files are copied when running the tar command to copy files in a view

A user wants to tar up files that have a label applied to them, but sees other files listed in the view that should not be included and wants to know what files will be included in the tar file.

In this example we only want to tar up files that have the RELEASE1 label applied to them, but are not sure if other non-labelled files will also get copied.

EXAMPLE:

The view
config spec has the following label rule:

prompt% cleartool catcs
element * CHECKEDOUT
element * RELEASE1
#element * /main/LATEST

The output of a directory listing shows 2 elements with the notation no version selected
prompt% cleartool ls
bar.c@@ [no version selected]
foo.c@@/main/1                  Rule: RELEASE1
lost+found@@ [no version selected]
patches@@/main/1                Rule: RELEASE1

 

Answer

The tar command will not copy files that are not seen in the view or, in the case of the above example, do not have the RELEASE1 label applied to them.


prompt% tar cvf RELEASE1.tar *
tar: bar.c: No such file or directory
a foo.c 1K
tar: lost+found: No such file or directory
a patches/ 0K
a patches/bug_patch 1K
tar: patches/doc_patch: No such file or directory

prompt% ls -l
total 10
-rw-rw-rw-   1 fokeefe  user        4096 May 19 16:42 RELEASE1.tar
-r--r--r--   1 fokeefe  user          29 May 19 16:36 foo.c
drwxrwxrwx   2 fokeefe  user         162 May 19 16:38 patches

The following command output shows the contents of the tar file where only the labelled files were copied:
prompt% tar tvf RELEASE1.tar
tar: blocksize = 8
-r--r--r-- 22234/20      29 May 19 16:36 2008 foo.c
drwxrwxrwx 22234/20       0 May 19 16:38 2008 patches/
-r--r--r-- 22234/20      29 May 19 16:37 2008 patches/bug_patch

Ownership

5.   How do I - change the ownership of a view on UNIX and Linux

The following scenario illustrates the steps required to reprotect a view on UNIX and Linux.

Changing ownership of a view requires modification of both the view file system objects and the view database entries to reflect desired ownership.

Note: Changing ownership of a view on Microsoft® Windows® cannot be done using operating system commands similar to the following due to the manner in which the ClearCase architecture interacts with the operating system. These steps will only work on UNIX and Linux.

 

File System Objects

The file system objects include the view storage directory files and all view private files stored in the source (.s) directory.

Example: The following scenario uses the view test to illustrate the affects of the changes made.

%cleartool mkview -tag test /home/jdoe/test.vws
Created view.
Host-local path: host1:/home/jdoe/test.vws
Global path: /net/host1/home/jdoe/test.vws
It has the following rights:
User : jdoe : rwx
Group: ccusers : r-x
Other: : r-x

1.     Before changing the view permissions, be sure to uncheckout any elements and backup the view to maintain a history of the view-private files to avoid any problems that may occur if a restore is required.

2.     End the view_server process for the view you wish to change ownership on using the command:

cleartool endview -server test

Note: When you list the view again, you should no longer see an asterisk on the far left of the line entry:

~$ cleartool lsview test
 test                /net/host1/home/jdoe/test.vws

3.     If you do not have /opt/rational/clearcase/etc/utils in your path, cd to that directory.

4.     SU to root and run the fix_prot command as follows:

fix_prot -r -chown <username> <view_storage_path>

Note: This utility will change the file system objects within the view storage. It will not change the view database permissions. The fix_prot utility is designed to correct inconsistencies within the VOB/View storage directories (.identity and files) in the event that they become misprotected. Review the related information below for more details about fix_prot.

You will be prompted to confirm; type
yes.

~# fix_prot -r -chown user2 /net/host1/home/jdoe/test.vws
CAUTION! This program reprotects every file and directory in a
storage directory tree and should be used only when the
protection has been damaged (e.g., through the process of copying the tree or by direct manipulation through a tool like the File Manager/Explorer).
Re-protect "/home/jdoe/test.vws"?  [no] yes
Protecting "/home/jdoe/test.vws/db"...
Protecting "/home/jdoe/test.vws/admin/view_space"...
Protecting "/home/jdoe/test.vws/admin"...
Protecting "/home/jdoe/test.vws/.s/00048"...
Protecting "/home/jdoe/test.vws/.s/00051"...
...
Protecting "/home/jdoe/test.vws/.s/00035"...
Protecting "/home/jdoe/test.vws/.s"...
Protecting "/home/jdoe/test.vws/.identity"...
Protecting "/home/jdoe/test.vws"...
Reprotection complete.

5.     Check the .identity directory of the view storage to ensure the setuid/setgid bit (sticky bit) is applied:

INCORRECT PERMISSIONS:
~# cd /home/jdoe/test.vws/.identity
~# ls -al
total 8
drwxrwxr-x  2 user2 ccusers 4096 Sep 25 05:02 .
drwxrwxr-x  6 user2 ccusers 4096 Sep 25 10:08 ..
-r----x---  1 user2 ccusers    0 Sep 14 17:24 gid
-r--------  1 user2 ccusers    0 Sep 14 17:24 uid


Modify the permissions on the gid and uid files if needed:

chmod 2410 gid

chmod 4400 uid

CORRECT PERMISSIONS
~# cd /home/jdoe/test.vws/.identity
~# ls -al
total 8
drwxrwxr-x  2 user2 ccusers 4096 Sep 25 05:02 .
drwxrwxr-x  6 user2 ccusers 4096 Sep 25 10:08 ..
-r----s---  1 user2 ccusers    0 Sep 14 17:24 gid
-r-S------  1 user2 ccusers    0 Sep 14 17:24 uid


At this point all the view file system objects have been reprotected and will reflect the ACL of the new owner.


Note: The ownership of the view file system objects is now complete. If there are also view private files, continue with the instructions on changing the view database ACLs for these files.


View Database Objects

If you need to change the permissions of a view private file, it must be done using the UNIX/Linux chown, chgrp or chmod command while set in a view/VOB context.



%cleartool setview test

test(view)%cd /vobs/VOB1

test(view)%ls -l test.txt
-rw-rw-r-- 1 jdoe ccusers 5 Nov 1 10:48 test.txt

test(view)%su
Password:

# chown user2 test.txt

# exit

test(view)%ls -l test.txt
-rw-rw-r-- 1 user2 ccusers 15 Nov 1 11:20 test.txt


Example scenario where reprotection is perfomed incorrectly and the affect it has on ClearCase operations.

%cleartool mkview -tag test /home/jdoe/test.vws
Created view.
Host-local path: host1:/home/jdoe/test.vws
Global path: /net/host1/home/jdoe/test.vws
It has the following rights:
User : jdoe : rwx
Group: users : r-x
Other: : r-x

%cleartool setview test
test(view)%cd /vobs/VOB1

test(view)%echo blah >test.txt


test(view)%cat test.txt
blah

test(view)%ls -l test.txt
-rw-rw-r-- 1 jdoe users 5 Nov 1 10:48 test.txt

test(view)%mvfsstorage test.txt | xargs ls -l
-rw-rw-r-- 1 jdoe users 5 Nov 1 10:48 /home/jdoe/test.vws/.s/00038/800000034548c1cctest.txt


Note: The view private file ACLs match that of the view properties. These ACLs are recorded in the view database.


test(view)%su
Password:


# chown vobadmin /home/jdoe/test.vws/.s/00038/800000034548c1cctest.txt

# chmod 644 /home/jdoe/test.vws/.s/00038/800000034548c1cctest.txt

# exit


test(view)%ls -l /home/jdoe/test.vws/.s/00038/800000034548c1cctest.txt
-rw-r--r-- 1 vobadmin users 5 Nov 1 10:48 /home/jdoe/test.vws/.s/00038/800000034548c1cctest.txt

Note: The permissions were changed to the file system object (specifcially the storage container for the view private file). The view private data container ownership changes to vobadmin.

test(view)%ls -l test.txt
-rw-rw-r-- 1 jdoe users 5 Nov 1 10:48 test.txt

Note: The ACLs haven't changed on the view private file in the VOB context (neither the owner or the permissions). This information is stored in the view database and cannot be changed using file system commands outside of the view/VOB context.


# su jdoe

test(view)%echo blah >>test.txt

test(view)%cat test.txt

blah
blah

Note: The original user (jdoe) can still write to file, although the data container permissions are set to not allow it.

# su vobadmin

Password:

test(view)%ls -l test.txt
-rw-rw-r-- 1 jdoe users 10 Nov 1 10:51 test.txt

test(view)%mvfsstorage test.txt | xargs ls -l
-rw-r--r-- 1 vobadmin users 10 Nov 1 10:51 /home/jdoe/test.vws/.s/00038/800000034548c1cctest.txt

test(view)%echo blah >>test.txt
zsh: permission denied: test.txt

test(view)%id
uid=4009(vobadmin) gid=16148(web_ts_ccase)

Note: The new owner (vobadmin) does not have permission to write to this view private file, despite the data container permissions.

test(view)%chown vobadmin test.txt
test.txt: Permission denied

test(view)%chgrp web_ts_ccase test.txt
test.txt: Permission denied


Note: The new owner (vobadmin) cannot change the permission of this view private file, despite the data container permissions.


The only solution is to chown the file within a view/VOB context.

test(view)%su
Password:

# chown vobadmin test.txt

# su vobadmin

test(view)%echo blah >>test.txt


test(view)%cat test.txt
blah
blah
blah

test(view)%ls -l test.txt
-rw-rw-r-- 1 vobadmin users 15 Nov 1 11:20 test.txt

Note: After a chown is run on the view private file in a VOB context, the new view owner is able to write to the file.

Storage

6.   How do I - run du -sk in a ClearCase view reports wrong size on Linux

If running du -sk on Linux in a ClearCase view the size reported will show approximately twice the size of the actual size of disk usage

 

Cause

du" on Linux (and Unix) will report the disk usage.

The switch 's' reports only the total sum for each of the specified files. The k switch reports the files sizes in units of 1024 bytes, rather than the default 512-byte units. If running du -sk in a ClearCase view the reported size will be wrong.

 

This issue has been identified as a product defect under APAR PK65529.

7.   How do I – understand the Error: view_server died on startup; marking it as down

When running cleartool setview on UNIX®, the following error is observed in the albd_log.

Error: server: view_server died on startup, marking it as down.

 

Cause

There are many reasons for this to happen, moving the view and NOT killing the view_server process, changing permissions, or like actions.

 

Resolving the problem

TROUBLESHOOTING TIPS:

1.     cd to the storage directory (.vws directory)

2.     Remove (rm) the .pid (this will get recreated when the view is set or started)

3.     Verify the permissions on the .identity directory (the permissions should be 700 and owned by the view owner)

4.     cd into .identity and verify the permissions of the files (ls -l). There should be at least two files; uid and gid. If there are more, they would look like group.xxx ('x' represents digits).

Example
-r-S------ uid
-r----s--- gid
-r----s--- group.123

If these do not look like this do a unix chmod:

chmod 4400 uid
chmod 2410 gid group.123


Note: All these files are owned by the view owner, but with the appropriate groups.

5.     cat the view_db.state file. This file should only contain the lower case 'i' (no quotes)

grep view_server (ps -ef | grep view_server), if one is running for this view and kill it ( 'kill -9 <pid>')

Note: Running cleartool endview -server <view-tag> does not always work in this situation since the view server is not accessible.

 

8.   How do I – understand the issue that registered view storage location created with a non global pathname cannot be used with dynamic views

This technote explains how to resolve an error cleartool: Error: A non-nil global pathname value is required for Dynamic views, that can occur when attempting to create a IBM® Rational® ClearCase® (CC) dynamic view using a registered view storage location (stgloc) that has no global path.

Symptom

Errors like the following are reported when attempting to create a dynamic view using a stgloc that does not have a global path defined :

cleartool: Error: A non-nil global pathname value is required for Dynamic views


Example:
cleartool mkview -tag viewname -stgloc view2
cleartool: Error: A non-nil global pathname value is required for Dynamic views.
Exit 1

Here are the details about the stgloc being used in the above mkview command:

Name: view2
  Type: View
  Region: unix
  Storage Location uuid: 7c590965.8f0311dd.8aa7.00:01:80:9f:0a:a5
  Global path: <no-gpath>
  Server host: myhost
  Server host path: /scratch/view2

Cause

The registered view storage location was created without a global path defined.

A stgloc created with a non global path can not be used with dynamic views, which relies on the global path for accessing the view's storage location.

Resolving the problem

Define a global path for the registered view stgloc.

Examples:

OR

cleartool mkview -tag defoe -stgloc viewstg
Created view.
Host-local path: myhost:/scratch/viewstg/user1/defoe.vws
Global path:     /net/myhost/scratch/viewstg/user1/defoe.vws
It has the following rights:
User : user1    : rwx
Group: user     : rwx
Other:          : r-x

9.   How do I – regenerate or replacing view storage files

ClearCase view files in the view storage area can be regenerated or replaced if problems occur with a view. The following files are automatically regenerated when the view is restarted:

·          .access_info

·          .pid

 

a)    Files that can be regenerated with ClearCase commands:

·          .compiled_spec -- regenerate by running cleartool setcs -current

·          .hostname -- regenerate by unregistering and re-registering the view

·          view.dat -- Snapshot views only: can be regenerated by running the "regen_view_dot_dat.pl" script found in <cc-home-dir>\etc\utils

 

b)    Files that can be manually replaced by making a new view on the same machine as the same user, and copying the affected file(s) to the view storage:

·          config_spec

·          groups.sd

·          identity.sd

·          view_db.state (as long as the view is not in the process of being reformatted); db/view_db.dbd (for schema 9 views only; 2002.05.00 and earlier)

·          db/view_db_schema_version

·          .view - The copy obtained from the new view must be edited to contain the correct information for the old view as described below. The correct information can be obtained from the output of "cleartool lsview -long <old_viewtag>".


Line 1: the location of the view storage directory, in hostname:pathname format
Line 2: the view's UUID (unique identifier), which must not be changed
Line 3: the hostname specified in line 1

 

c)    Files that cannot be replaced:

All other files in the db directory except the ones mentioned above ( view_db_schema_version and view_db.dbd)

10.       How do I - rename a ClearCase View

To completely rename a ClearCase View requires that both the storage and the tag be renamed.

These operations can be performed from command line.

 

1.     Stop the view.
Run
cleartool endview <view-tag>
Note: For ClearCase only, any host that has a dynamic view started with the old name after the rename has been completed will need to be rebooted to clear the MVFS.

2.     Kill the view_server process. Run cleartool endview -server <view-tag>
Note: Stopping the ClearCase services on the host will also kill the process; refer to
technote 1134178 for directions on stopping the services.

3.     Remove the view-tag.
Run
cleartool rmtag -view <view-tag> to untag the view.

4.     Remove the ClearCase registry entry.
Run
cleartool unregister -view <view-storage-pname>.vws to unregister the view object.

5.     Rename the view storage directory:

·         UNIX or Linux
mv <old-view-storage> <new-view-storage>.vws

·         Windows
rename <old-view-storage> <new-view-storage>.vws

        Register the new name of the view storage.
Run
cleartool register -view <view-storage-pname>.vws

        Create a new tag for the view.
Run
cleartool mktag -view -tag <view-tag> <view-storage-pname>.vws

        Start the view.
Run
cleartool startview <new-view-tag>

11.       How do I - restore a view-private file from backup

Say for example one of the files in a view becomes corrupt (due to a power outage or other catastrophe), how can you recover this file if you have been backing up your views on a nightly basis?

 

DYNAMIC VIEW:

Note: The view storage directory (*.vws) needs to be backed up for dynamic views as this is where the file(s) will be recovered from.

 

To recover a view private file for a dynamic view, use the mvfsstorage command to find the path of the view private file (as it is not intuitive to locate) and replace the file with the back up copy:


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

1.     Open a command prompt, set into the view and cd into the VOB where the view private file resides.

2.     Run mvfsstorage <file>

Example:

M:\test_view\my_test_vob>cleartool ls
test_project@@\main\1 Rule: \main\LATEST
test.txt

M:\test_view\my_test_vob>mvfsstorage test.txt
E:\ClearCase_Storage\views\user1\test_view.vws\.s\00010\80000019422db43btest.txt


Note: The mvfsstorage command resides in the
<cchome>/etc directory on UNIX and Linux and must be run from that path,

3.     Navigate to the location of the file within the view storage directory of the backup and copy the file with the same name.

4.     Navigate to the location of the file within the view storage directory of the active dynamic view and delete the corrupted file(s).

5.     Replace the new file from the backup into that directory with the same name from the mvfsstorage output.

SNAPSHOT VIEW:

6.     Note: The view root (location where the files are loaded) needs to be backed up for snapshot views as this is where the file(s) will be recovered from.

7.     To recover a view private file for a snapshot view, find the copy of the view private file in the backup archive and replace the file in the active view with the copy (just like any normal operating system file restore.

12.       How do I - locate view private files in the storage directory

how to locate and recover view private files from an IBM® Rational® ClearCase® dynamic view storage directory, which can be useful when a view is damaged (and or unusable) or the view has been restored from backup.

 

On Microsoft Windows

1.     Open Windows Explorer, go into the view storage directory; view_name.vws

2.     Go into the .s sub-directory

3.     Located under this directory are many numbered directories. Browse through the numbered directories, searching for the view-private file. All the files that are listed in these directories are view-private files. The file names of the files will be preceded by an ID number.

·         Example:

The view private file, help.txt, in the directory under .s, is named, 241ae3df.000c.help.txt

                If manual searching is cumbersome, then use the search functionality from Windows Explorer > Tools -> Find -> Files or Folders... > and specify *filename* for the search string.

                Copy the file out to a non-ClearCase directory. When all of the view-private files have been copied out, remove the damaged (or restored) view storage. As it should not be registered or tagged in Rational ClearCase, you can use the operating system's Delete command.

                To copy the file back into Rational ClearCase, you will need to:

·         Rename the file from the .s directory back to its original name; 241ae3df.000c.help.txt to help.txt

·         Checkout the element in a new view

·         Copy the restored file from the local file system directory into the view

·         Checkin the element version

On UNIX or Linux

Use these directions to recover view-private changes from a corrupt or restored view:

1.     Save the old views .s directory in a temporary location

2.     Create a new view with same config spec

3.     Set the view and change directory (cd) into the VOB

 

Example:

The goal is to recover the view-private changes made to the file, foo.c, in the VOB directory, /vobs/myvob/src.

1.     Using a UNIX find, look for foo.c in the old .s:

% cd ../safeplace/.s
% find . -name '*foo.c'

2.     From within the new view

cd /vobs/myvob/src

3.     Use the cp command to copy foo.c to the current directory

cp ../safeplace/.s/0001/00cd0ef2.foo.c foo.c

Now the view private file is back in synch where it belongs.

The same procedure can be done for copies of checked out files the become corrupt or deleted.

1.     Cancel the checkout

cleartool unco foo.c

2.     In the new view, execute a checkout of the file

cleartool co foo.c

3.     Use the procedure outlined above to find the view-private copy that was stored in the old .s directory.

Note: There is no procedure to recover Non-Shared derived objects.

13.       How do I – understand the error Creating a new view in a view storage directory

Attempts to create a view using cleartool mkview or make view GUI functionality, results in the following error:

cleartool: Error: A view cannot be created under another view's storage directory or snapshot view storage directory.

This error will occur when you attempt to create a new view in a directory which contains other view related files such as .view files. These files will exist in a directory that is currently (or was) in use as a view storage directory.

Cause 2

This error has also been shown to be caused by left over view.dat files from snapshot views that were not removed correctly. The view.dat file resides in the view work space or view root; the location where the files are loaded.

Cause 3

Attempts to make use of an existing (dynamic) view storage directory using cleartool mkview will result in the above error.

 

Solution

As specified in the error, you cannot create a new view in an existing view's storage directory.

The location you specify for storing the new view should be a
ClearCase server storage location, a network share on Windows or an export on UNIX or Linux.

A network share is a location on a computer network, typically allowing multiple users on the same network to have a centralized space for storing and accessing data. You can review this
Microsoft article 301198 for more information.

An export on UNIX or Linux is a way to make a local resource available for mounting by remote systems. For more information, you should refer to the man page for export or share. Otherwise, consult your systems administrator.

When creating a view, you should be sure that the directory is not in use by an existing view and that it does not contain remnants of a previous view, which may have not been properly removed.

A view directory contains the following files and directories:


Refer to the IBM Rational ClearCase Administrator's Guide for more information on View Administration.


Solution 2


Check the selected location to store the snapshot view work space directory (view root) to see if any view.dat files exist.

Note: The view.dat files is a hidden file on Windows, so the option to show hidden files and folders in Windows Explorer will need to be enabled before a search can be conducted for these files.

If found, remove them and attempt the view creation again.


Solution 3

Use the these commands to get past this issue:


The view tag will now exist and the view can be started.

Note: You will need to be the owner of the view storage directory to create a tag for the view.

14.       How do I – understand about dot files in the view storage

View storage dot files:

.cow files

.mvfsxxxxxx files

.cmake.state files

Q: Is there a way users can manage the view storage area besides removing the view? Is recoverview the only option for cleaning these temporary files?

A: The
cleartool lsprivate command shows file usage in a view, for all VOBs involved.
cleartool space can be used to report a views disk space usage.

Review appropriate sections of the Rational ClearCase and Rational ClearCase LT Command Reference for usage and syntax of cleartool recoverview, cleartool lsprivate and cleartool space.

15.       How do I – understand about the view_db.state file

The view_db.state file is located in the top level of the view storage directory, and it indicates to the view_server what state the view is in upon restart of the view server process.

This state file allows the view_server to resume the operation of a given state if the operation is interrupted.

The states are:


i - idle
m - modified
d - dumped
r - recovery needed
n - new

In general, this file should not be modified as the view_server process writes to it.

Under normal circumstances, the view_db.state file will contain only the letter "i" (plus a carriage return).

Environment

16.       How do I - Prevent dynamic view sharing on Windows

Having the ability to prevent users from sharing information in dynamic views may be necessary during particular projects. Prevention from deleting or modifying checkedout files and or view privates can greatly impact the workflow of the project and it users.

On UNIX® or Linux®, dynamic view sharing can be controlled through use of the operating system umask function. The file mode creation mask (often called the umask) determines the default permissions for any file created by a given process. For example, a file created by the create command on UNIX has the permissions specified by the umask unless the create command specifies explicit permissions.

Windows does not use a umask to control file creation permissions; therefore, the views cannot be configured to restrict sharing the same way it can on UNIX. The Administrator's Guide suggests using the cleartool chview command to change the read-write properties of the view, but this solution is not very flexible.

Review the ClearCase Administrator's Guide on the topic of Access Control for View and View Objects for more details.

You can make use of the undocumented -vmode feature for views.

Q: What is -vmode?

A: The -vmode switch is used to mimic the umask function on UNIX for Windows views.

By default, the permission of a view during view creation time is 775 (where the User and Group have read, write, and execute permissions). This means if a user checks out a file, other users of the same group have permissions to start that view and modify or delete the checkedout versions (or view private files).

A line such as -vmode <mode> (where <mode> is a UNIX-style numeric permissions descriptor such as 0755) can be placed in the .view file located at the root of the View's storage directory.

If the line -vmode 0755 is added as the last line to the .view file, the properties of that View will show you that 'group' no longer has write permissions.

Example:

BEFORE:
C:>cleartool lsview -prop test_view
* test_view \\Host1\ccstg_e\views\jdoe\test_view.vws
Created 15-Sep-05.17:45:50 by DOM1\jdoe.DOM1\clearuser@host1
Last modified 22-Sep-05.11:54:02 by DOM1\jdoe.DOM1\clearuser@host1
Last accessed 22-Sep-05.11:54:02 by DOM1\jdoe.DOM1\clearuser@host1
Owner: DOM1\jdoe : rwx (all)
Group: DOM1\clearuser : rwx (read)
Other: : r-x (read)

·         Added -vmode 0755 to the .view file.

AFTER:
C:>cleartool lsview -prop test_view
* test_view \\Host1\ccstg_e\views\jdoe\test_view.vws
Created 15-Sep-05.17:45:50 by DOM1\jdoe.DOM1\clearuser@host1
Last modified 22-Sep-05.11:54:02 by DOM1\jdoe.DOM1\clearuser@host1
Last accessed 22-Sep-05.11:54:02 by DOM1\jdoe.DOM1\clearuser@host1
Owner: DOM1\jdoe : rwx (all)
Group: DOM1\clearuser : r-x (read)
Other: : r-x (read)

Review the ClearCase Administrator's Guide on the topic of View and VOB Access Control for more details on Protection Modes in ClearCase

17.       How do I – resolve the setting into a view from a shell script does not process the remaining commands in the script issue

When running the sample script below, all commands executed after the cleartool setview command are not processed because cleartool setview spawns a new shell:


#!/bin/sh
/usr/atria/bin/cleartool setview cmview
/usr/atria/bin/cleartool pwv
/usr/atria/bin/cleartool lsview
cd /vob/transition/Admin_transition
/usr/atria/bin/cleartool mkbrtype -global -nc 02b456

 

In the above script any commands that appear after the execution of cleartool setview cmview are not processed because a shell is spawned off with exec(), which replaces the current program with a new program.

 

This means current process's text and code segments, which in this case is the script that contains all the commands, is replaced by the program getting executed, which is the shell invoked by running cleartool setview cmview. Hence, none of the commands are processed beyond the point of invocation of the setview.

 

WORKAROUNDS:

1.     Run cleartool setview prior to calling the script
or

2.     Run the cleartool setview command and exec into the script

 

FAQ:

Q: How does setview select the subshell (csh, sh, ksh, bash ...) to spawn?

When cleartool setview is run, a new shell will be spawned. The shell chosen will depend on your default shell as defined in your NIS maps or your local /etc/passwd file.

You can verify your default shell as follows.

For NIS:
ypcat passwd | grep <username>

For local passwd file:
grep <username> /etc/passwd

The default shell is the last entry on the line.

For example:
$ ypcat passwd | grep jdoe
jdoe:sbe.p46JQm9kE:20147:5089:John Doe:/people/jdoe:/bin/bash


This example shows that the Bash Shell is the default shell (
/bin/bash).


Q: How do I override the default shell?

One way of overriding the default shell chosen by cleartool is to use the $SHELL environment variable.

Using the above example, even though the default shell is
/bin/bash, you can change the shell that cleartool uses by running:

$ setenv SHELL /bin/ksh
$ setenv | grep SHELL
SHELL=/bin/ksh


Now when cleartool is run, the Korn Shell (ksh) will be spawned, and not bash.


Q: How can I avoid losing my shell environment after setting into a view?

When running cleartool setview while logged in as a user whose default shell is ksh, the ksh environment is not picked up. Why?

In this setup, spawning a shell executes .profile but does not execute .kshrc. To be able to use the environment you have setup in .kshrc, add the following lines to your .profile:

ENV=$HOME/.kshrc
export ENV


The ENV command forces it to run .kshrc as well.

The export command forces the shell to pass that value onto the setview subshell, thereby setting up the environment.

Note: Review the man pages for the other shells to determine the files to edit following the concepts above.

 

18.       How do I - get around the issue of cleartool setview –exec spawning a new shell

To get around the issue of cleartool setview –exec spawning a new shell try the following:

 

a).   Replace cleartool setview with cleartool startview

b).   Replace the Perl exec with system

c).   Replace and references to files within the view to use view extended pathnames when accessing VOB data.

/view/<view tag/<vob mount>/<vob tag/<directory path>/<file name/s>

19.       How do I - run xclearcase at setview time

To start the xclearcase GUI in UNIX at  set view time use the following command:

 

cleartool setview –exec xclearcase <view name>

20.       How do I – understand about the .view file

About the .view file

When a view is created, a .view file is created in the view storage directory and contains the basic information about the view as defined by the options that can be used to create the view.

Review the ClearCase Command Reference Guide on the topic of mkview (cleartool man mkview) for more information on which options can be used to create a view.

The file contains the following data:

Example: A UCM webview not sharing DOs configured with 5000 bytes view cache as a strip_cr mode view.

host2:c:\ClearCase_Storage\views\DOM1\user1\test.vws

bc4e0eb4.4211442e.a6f1.6e:58:c9:ed:89:3c

host1

-sumview

-webview

-cache 4096

-nshareable_dos

-textmode strip_cr


Problems associated with missing a .view file

In Windows Explorer, when you right click on a dynamic view the following error pops up:

*******************************************
ClearCase View Profiles

Cannot determine if the view is associated
Error getting view handle.
*******************************************

First try to stop the view and the server process at the command prompt:

cleartool endview -server <view tag>


Then try to start the view from command prompt:

cleartool startview <view tag>


The following error should appear:

view_contact call failed: RPC: Unable to receive; errno = [WINSOCK] Connection reset by peer
cleartool: Error: Error trying to contact view_server for view host1:C:\views\test_view.vws: No such file or directory
cleartool: Error: Couldn't set view tag test_view: No such file or directory


Try to remove the view from command line:

cleartool rmview <UNC path to view storage>

ClearCase will complain that the object is not a view.


cleartool: Error: \\host1\views\test_view.vws isn't a view: No such file or directory
cleartool: Error: Unable to remove view "\\host1\views\test_view.vws".


These symptoms can be associated to a missing .view file.

This file stores the view's Universal Unique identifier (UUID) and some attributes about the view in the view storage directory.

You must manually remove the view from the ClearCase registry as well as the file system.

Note:
cleartool unregister -view will not work in this case as we need to specify the view's UUID.

1.     Run cleartool lsview -l <view-tag> to get the view's UUID

2.     Run cleartool unregister -view -uuid <view-uuid-obtained-in-step-1> to unregister the view

3.     Run cleartool rmtag -view <view-tag> for this view. Be sure to remove the view tag(s) from all regions to which this view is tagged

4.     Delete the View storage directory (from the above example: C:\views\test_view.vws) on the file system.

Moving a view and the .view file

Moving a view from one host to another host does not modify the .view file in the view storage directory to reflect the new location information.

This is expected behavior.

The information stored in the .view file always describes the view's first incarnation.

Related information

Regenerating or replacing view storage files
Moving the view storage location of a ClearCase Web vie
About .compiled_spec and config_spec
About the .pid file

21.       How do I – understand about View Profiles

About View Profiles
Base ClearCase includes a set of deprecated features called view profiles, which you can use to automate much of the work flow required to set up and maintain your team’s shared ClearCase configuration.

Note: The Unified Change Management (UCM) process provides a more complete solution for organizing software development teams and has replaced all of the view profile functionality. Review Appendix A in the Managing Software Projects guide for information on moving from view profiles to UCM.

Enabling View Profiles
The first thing that needs to be established is the share to which the view profiles will be stored for all clients to use. The Windows share must be accessible to all ClearCase users.

Once the share is created, you can activate View Profiles on the clients.

1.     Open the ClearCase Properties control panel applet (Click Start > Run type cc.cpl)

2.     Click on the Options tab.

3.     Check the Use view profiles for creating views radio button

4.     Enter the path the Windows share where the view profiles will be stored.

5.     Click OK


Creating View Profiles

1.     Open the View Profile Explorer to create and work with the view profiles.



You can access the View Profile Explorer as follows:

·         Start > Run type clearprojtool
Note:
This command only works if View Profiles are enabled in the ClearCase control panel applet.

·         From the GUI through the ClearCase Home Base on the Branches tab



Note:
Prior to enabling View Profiles, if you used the ClearCase Home Base GUI, you may have noticed that there was not a Branches tab and if there was, only the Merge Manager appeared. After enabling View Profiles, there will be new options available.

Example before View Profiles were enabled:

                Once the View Profile Explorer is open, create a view profile.




Fill in the fields for Step 1 and click Next




Select the VOB to be worked on for the project along with any related AdminVOB and click Next




Choose the branching strategy to deploy. Click Next

Note: This example will work on a branch other than main.




Choose the baseline label (checkpoint) to start from and click Next

Note: The project needs to be set up prior to configuring the view profile that includes a labeled set of elements to start from. In this example, the INITIAL label has been applied within the VOB \import.




Use an existing branch or create a new branch type to represent the shared location (integration branch) for the profile to merge to and click Next




Update the diagram (if needed) which helps represents the work flow of the view profile (visually). When complete, click Next

Example modification:

Click Tool Palette



Review the specifications of the view profile (including the config spec) and click Finish

Note: To see how to predefine load rules for snapshot views review
technote 1248095 for more details.

You will now see the first (of many) View Profiles in the list

 

Using View Profiles

Everything else you need to know about View Profiles can be found in the on-line Help

Click Help > Using View Profile Explorer



FAQs

·         Why can't the config_spec for a view be edited when the view is associated with a view profile?

This is by design. The only changes permitted fall in the middle of the config spec, as identified below:

# [CC_PROJECT - ClearCase View Profile Information
#               Name - \ClearCase View Profiles\integ_branch
#               ID - c44d6ae3-4b77-25f7-8ba8-1235e1474da 0.2
#
element * CHECKEDOUT
#
#             Any modifications to this config spec should
#             be made following this comment.
# CC_PROJECT]

<-------In this section you can add additional rules

# [CC_PROJECT - View Profile Config Spec
#             Do not directly modify the text below, it has been
#             automatically generated by the ClearCase View Profile Tool.

element * ...\integration\LATEST
element * REL1 -mkbranch integration
element * \main\0 -mkbranch integration
# CC_PROJECT]

·          

Why do I see the following error starting my view?

Unable to perform view start-up operations related to the "view_tag" view's
ClearCase View Profile association.
Error 0x3e9 trying to mount VOB"\vob_tag"


The error is generated because the VOB that was removed is referenced in the view profile. Open the View Profile Explorer and edit the associated view profile and remove the VOB from the current VOB list.

22.       How do I – understand about the .specdev file in /view directory

The .specdev file is a character special device file. It is used for all client communication, like cleartool, clearmake, clearaudit, and other ClearCase commands and processes.

 

If this file is not present, errors such as the following may occur:

cleartool: error: Unable to create directory < viewtag >: not a clearcase object.

RECREATE FILE

To recreate a missing .specdev file, cd to the /view directory and issue the following commands as root:

1.     mknod .specdev c 0 0x000000

2.     chmod 444 .specdev

3.     chown root:root .specdev


Note: More information on special devices can be found by running man ioctl.

23.       How do I – understand about the Active flag for dynamic and shapshot views

ClearCase checks the viewroot directory, typically /view on UNIX® and Linux® and the MVFS drive (by default M:\) on Microsoft® Windows®, for the presence of a view tag to report the Active state.

 

DYNAMIC VIEWS

Dynamic view tags are activated and made visible within the viewroot directory by starting the view using either the cleartool startview <view tag> (Windows) or cleartool setview <view tag> (UNIX/Linux) commands.

If the view tag is present in the viewroot directory, then the view's ACTIVE state is set to YES.

A dynamic view, will correctly display if that view is active or not.

 

Note: The * indicates the dynamic view is started.
C:\>cleartool lsview
* dynamic_view         \\Host\ccstg_c\views\dynamic_view.vws
  snapshot_view        \\Host\ccstg_c\views\snapshot_view.vws
  dynamic_view2        \\Host\ccstg_c\views\dynamic_view2.vws


C:\>cleartool lsview -long dynamic_view
Tag: dynamic_view
  Global path: \\Host\ccstg_c\views\dynamic_view.vws
  Server host: Host
  Region: windows
Active: YES
View tag uuid:cd20acf1.f1cd4915.adde.65:03:52:0d:4f:26
View on host: Host
View server access path: c:\ClearCase_Storage\views\dynamic_view.vws
View uuid: cd20acf1.f1cd4915.adde.65:03:52:0d:4f:26
View owner: jdoe

C:\>cleartool lsview -long dynamic_view2
Tag: dynamic_view2
  Global path: \\Host\ccstg_c\views\dynamic_view2.vws
  Server host: Host
  Region: windows
Active: NO
View tag uuid:25244aac.2a2148bd.9ca2.e4:1c:f4:bc:af:2e
View on host: Host
View server access path: c:\ClearCase_Storage\views\dynamic_view2.vws
View uuid: 25244aac.2a2148bd.9ca2.e4:1c:f4:bc:af:2e
View owner: jdoe

SNAPSHOT VIEWS

Snapshot views cannot be activated using the startview or setview command; therefore, a snapshot view tag is never made active in the viewroot directory.

So based on how ClearCase checks the active state of a view, a snapshot view will always show the status as inactive (Active: NO) even if a corresponding view server process is running for that view.

C:\>cleartool lsview -long snapshot_view
Tag: snapshot_view
  Global path: \\Host\ccstg_c\views\snapshot_view.vws
  Server host: Host
  Region: windows
Active: NO
View tag uuid:0b5c58e8.0d7243c9.81db.1c:d5:1b:e5:8e:2f
View on host: Host
View server access path: c:\ClearCase_Storage\views\snapshot_view.vws
View uuid: 0b5c58e8.0d7243c9.81db.1c:d5:1b:e5:8e:2f
View attributes: snapshot
View owner: jdoe

24.       How do I - configure a time-out session for idle views

CONFIGURE VIEW SERVER PROCESS TIMEOUT PERIOD

A new feature was introduced in the following patches that allocates a time-out period for view server processes whereby they terminate themselves automatically.

Snapshot Views Only

The new feature was introduced with SNAPSHOT VIEWS ONLY in the following releases:

2003.06.00

clearcase_p2003.06.00-14

Full ClearCase UNIX

Service Release 4

Full ClearCase & CCLT Windows

clearcase_lt_p2003.06.00-10

CCLT UNIX

 

2002.05.00

clearcase_p2002.05.00-40

Full ClearCase UNIX

clearcase_p2002.05.00.NT-34

Full ClearCase Windows

clearcase_p2002.05.00-19

CCLT UNIX

clearcase_lt_p2002.05.00.NT-13

CCLT Windows



Dynamic Views:
The new feature was expanded to include dynamic views in ClearCase version 7.0.


INSTRUCTIONS:

To extend or shorten the time-out session, set the
CCASE_VIEW_IDLE_THRESH variable to the appropriate number of seconds.

Note: The default (and minimum) time-out for the snapshot view server processes using the variable is 2 hours and 10 minutes (7800 seconds).

Setting the
CCASE_VIEW_IDLE_THRESH to 0 (zero) turns off the time-out session (i.e., snapshot views never go idle.)

The following formula can be used to assist in calculating the number of seconds:

(h * 60 * 60) + (m * 60) = total seconds

Where h = hours and m = minutes.

Example: To calculate a 3 hour and 15 minute time-out value in seconds.

3 * 60 * 60 = 10800
15 * 60 = 900

10800 + 900 = 11700 seconds

The environment variable can be set on Windows as a system EV and on UNIX or Linux can be applied by editing the startup script (
ccase-home-dir/etc/clearcase or ccase-home-dir/bin/atria_start) to control the idle time-out.

Note: After the time out period has elapsed, running cleartool lsview may still show the dynamic view as active (an * will precede the name) or running cleartool lsview -long will show active flag set to YES. This "active" status does not refer to the state of the server process. It refers to having an open "handle" in the MVFS, local to the machine running lsview.

 

MANUALLY

If you don't have the above patches installed to better manage this behavior, you need to end the view server process. From the command line, run the cleartool endview -server command to stop the view server process after you have exited the view or are finished using it.

If running this command manually is not a viable option, consider creating a script to automate the job (see UNIX or Linux reference below for an example). There is no known script to use on Windows currently.


SCRIPT EXAMPLE (UNIX or Linux):

Here is an optional script that can be run on UNIX or Linux:

1. Create a shell script (in this example the script is named "quit") and make it executable.

=============
#! /usr/bin/sh
# this script is called "quit"

cleartool pwv -short |xargs cleartool endview -server
exit
=============


2. When exiting the view shell on UNIX or Linux, run "quit" instead of "exit" and the process will be terminated.

25.       How do I - copy all view private files and Derived objects between views

In order to move all view private files from one view to another, the following types of files must be moved or copied:

o    Derived Objects (Dynamic views only)

o    View-private copies of checked-out elements

o    "Other" view private files

 

Derived Objects

The best method to move Derived Objects from one dynamic view to another is to promote the DO's from the old view to the VOB and then wink the DO into the new view.

The process is as follows:

1.     Start and or set to the old view
Note: Ensure all VOBs referenced by this view are mounted; otherwise, you will receive VOB not Mounted... errors during steps 2 and 3 below.

2.     Run the following command to create a list of all DO's in this view for later use. This list is relative to the root of the view, taking the rest of this procedure possible with a minimum of editing required.

3.     Windows:
cleartool lsprivate -do > c:\dolist.txt


UNIX/Linux:

cleartool lsprivate -do > ~/dolist.txt

4.     Run cleartool lsprivate -do | view_scrubber -p

This promotes ALL DOs to the VOB.

 

Another method to use involves winking the files into the new view.

Note: This is strictly optional since any wink-ins needed will be accomplished during the next clearmake or omake build.

1.     Start and or set to the old view

2.     Run the following command to wink in all DOs created in the initial view:

Windows:

for /F "delims==" %x in (C:\dolist.txt) do cleartool winkin "%x"


UNIX/Linux:

cat ~dolist.txt | xargs -i cleartool winkin {}

 

VIEW-PRIVATE FILES

There are 2 remaining types of view private files. View-private copies of checked-out files and "other" view private files.

The best means to save the checked-out files is to check those files back in. This is by far the best way to save work in progress.

If, on the other hand, you are working in a shared branch or UCM stream, and checking could impact your colleague's work, run the following commands to undo all checkouts, keeping the checked-out files as view private files with .keep extensions.

1.     CD into the old view.

2.     CD into each VOB and run this command:

Windows:
for /F %x in ('cleartool lsco -all -cview') do cleartool unco -keep "%x"


UNIX/Linux:

cleartool lsco -all -cview | xargs -i cleartool unco -keep {}

 

Saving other view private files can be done any number of ways. You can either copy them manually, or use a third-party archive utility to move the files.

On Windows, the process for saving other view private files without using third party tools is:

1.     Ensure that a drive is mapped to both the old and new views.

2.     CD or set into the old view.

3.     Run the following command to list all remaining view private objects:

for /D %x in (*.*) do cleartool ls -view_only -recurse %x >C:\rest.txt

One option to avoid ".contrib" files created by merge operations (including UCM delivers and merges) is to filter the output in as illustrated below:

cleartool ls -view_only -recurse| find /V ".contrib > C:\Otherlist.txt"

This will filter out all files that contain the string ".contrib" in their names, potentially narrowing the list of files to review considerably.

4.     Edit the file list to include only files you wish to copy, save it as "Filteredlist.txt".

5.     Run this command to copy the desired files from the old view to the new one (If X: is the old view and Y: is the new one):

for /F "delims==" %a in (C:\FilteredList.txt) do copy "X:%a" "Y:%a"

On Windows, this operation can be dramatically simplified through the use of third-party archive tools.

For example, the same procedure using the
Info-Zip third party toolkit can be done as follows:

1.     CD into the old view.

2.     Run the following command:

for /D %x in (*.*) do cleartool ls -view_only -recurse %x | zip -m -@ c:\tempzip.zip

3.     CD into the new view

4.     Run the following command:

unzip c:\tempzip.zip

 

On UNIX, however, archiving all the view-private files in a view can be condensed to a single command line.

That command line is:

tar cvf ~/myfiles.tar `cd /vobs;ls -1|xargs -i cleartool ls -view_only -recurse {}`


To reverse this process in UNIX , set into the new view and run the below command line:

cd /vobs;tar xvf ~/myfiles.tar

26.       How do I - copy file versions from ClearCase using cleartool find on UNIX or Linux

You can copy certain versions out of your view to the local filesystem 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'


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

27.       How do I – understand text modes (msdostext_mode)

Text Modes and Changes to the VOB
All new VOBs created in 2002.05.00 and later will be MSDOS enabled by default.

Note: For versions before 2002.05.00, running msdostext_mode on a VOB makes a change to the VOB database, which lets the VOB database store both the UNIX and MSDOS file lengths (sizes) for any given version of an element.

Running msdostext_mode does not create additional source containers, but will result in additional cleartext generation for the alternate text mode.

Text Modes and Individual Elements
To check if a particular element version has been converted for msdostext_mode, use the "cleartool dump <filename>" command. Under heading "stored fstat", there is an entry for "mode". If mode is set to "00", then the version has NOT been converted with the msdostext_mode utility. If mode has a value other than "00", the version has been converted.

Example (not converted):
stored fstat:
ino: 0; type: 1; mode: 00; uid: 4294967294; gid: 4294967294

^^

Example (converted):
stored fstat:
ino: 0; type: 1; mode: 021; uid: 4294967294; gid: 4294967294

^^^

Text Mode and Views
To determine the mode of a view, use the "cleartool lsview -properties -full <viewtag>".

Transparent text mode is displayed as unix, strip_cr text mode is displayed as strip_cr, and insert_cr text mode is displayed as msdos.

Examples:
%>cleartool lsview -prop -full strip_cr
strip_cr \\kis2\ccstg_e\views\KIS2\jdoe\strip_cr.vws
^^^
Text mode: strip_cr
^^^

%>cleartool lsview -prop -full insert_cr
insert_cr \\kis2\ccstg_e\views\KIS2\jdoe\insert_cr.vws
^^^
Text mode: msdos
^^^

%>cleartool lsview -prop -full transparent
non-share-do \\kis2\ccstg_e\views\KIS2\jdoe\transparent.vws
^^^
Text mode: unix
^^^

Alternatively, you can view the contents of the ".view" file in the view storage directory. For transparent mode views, there will be nothing indicated about text modes. For insert_cr mode views, there will be a line that reads "-textmode msdos". For strip_cr mode views, there will be a line that reads "-textmode strip_cr".

 

Text Mode and Cleartext
Cleartext created for an insert_cr mode (msdostext_mode) view will have an ".msdos" extension at the end of the cleartext file name.

In a dynamic view you can use the "mvfsstorage <version>" or use the "cleartool dump <version>" to view the cleartext container.

Tips on Troubleshooting
If you have problems with file truncation or file contents when using text mode views there are some basic troubleshooting techniques you can use.

Note the following example of using UNIX and DOS mode views to access an element.

1. Make sure the text mode for the view is the intended one (using the steps above).

2. Verify that the VOB has been msdostext_mode enabled and that the file version in question has been converted.

3. Make sure the view text mode matches the type of editor being used.

4. Check the type of machine the file is being accessed from (Windows or UNIX).

For example, if the answers to the above were:

1. -textmode msdos
2. Yes and yes
3. Notepad
4. Windows

Then the file should look correct. In other words, the correct mode of the view being used.

If the answers are:

1. -textmode msdos
2. Yes and yes
3. Emacs
4. UNIX

Then the file will NOT look correct since Emacs is a UNIX-based editor. So, in this case, the correct version of the cleartext is not being presented to the editor due to the mode of the view being used.

If the answers are:

1. Nothing relating to tmode
2. No and no.
3. Emacs
4. UNIX

Then the file should look correct. In other words, the correct version of the cleartext is being presented to the editor based on the mode of the view being used.

28.       How do I – understand the supplement to the Command Reference Guide about cleartool lsview -age

Which events prompt cleartool lsview -age to provide the last time a view was accessed?

The following events qualify a view being accessed:

1.     Check in and Check out

2.     Writing or creating a Derived Object

3.     Winkin of a Derived Object

4.     Promotion of a Derived Object

5.     Setting a config spec

6.     Reading a view private file

7.     Writing a view private object

Why doesn't that time change when one of these events occur and cleartool lsview -age is run?

Running cleartool lsview -age with or without a view-tag will generate an updated access date and time, but this is not instantaneous.

It takes approximately 60 seconds to update the access date and time.

Example:
B:\my_test_vob>date
The current date is: Tue 04/06/2002

B:\my_test_vob>time
The current time is:  8:29:03.45

B:\my_test_vob>cleartool lsview -age test_view
* test_view          \\host\ccstg_c\views\DOMAIN\user\test_view.vws
Last accessed 05-Aug-02.07:15:01 by DOMAIN\user.DOMAIN\group@host.rational.com

B:\my_test_vob>cleartool setcs -current


*****************************************************************
Note the time - the output has not been updated yet.
*****************************************************************

B:\my_test_vob>date
The current date is: Tue 04/06/2002

B:\my_test_vob>time
The current time is:  8:29:33.25

B:\my_test_vob>cleartool lsview -age test_view
* test_view          \\host\ccstg_c\views\DOMAIN\user\test_view.vws
Last accessed 05-Aug-02.07:15:01 by DOMAIN\user.DOMAIN\group@host.rational.com

*****************************************************************
After waiting 60 seconds or longer the output has changed
*****************************************************************
B:\my_test_vob>date
The current date is: Tue 04/06/2002

B:\my_test_vob>time
The current time is:  8:30:04.37

B:\my_test_vob>cleartool lsview -age test_view
* test_view          \\host\ccstg_c\views\DOMAIN\user\test_view.vws
Last accessed 06-Aug-02.08:29:14 by DOMAIN\user.DOMAIN\group@host.rational.com

29.       How do I – understand about the view_db.state file

The view_db.state file is located in the top level of the view storage directory, and it indicates to the view_server what state the view is in upon restart of the view server process.

This state file allows the view_server to resume the operation of a given state if the operation is interrupted.

The states are:


i - idle
m - modified
d - dumped
r - recovery needed
n - new

In general, this file should not be modified as the view_server process writes to it.

Under normal circumstances, the view_db.state file will contain only the letter "i" (plus a carriage return).

30.       How do I – understand the “Too many open files error in view_log” issue

The view_server process is reporting the following errors in the view_log during a build after upgrading to ClearCase 7.x:

Too many open files

 

Cause

The view_server is running out of small file descriptors.

Defect APAR PK58979 has been opened to investigate this issue.

To be added to the list of clients reporting this issue, contact IBM Rational ClearCase support.

 

Resolving the problem

There is currently no resolution or workaround available for this defect.

 

Config specs

31.       How do I - prevent other users from modifying my view's config spec on UNIX and Linux

 

Users other than the view owner have been changing the view's config spec and I need a way to stop this from occurring. How can this be done when the view's permission's currently allow write privileges to the view's storage directory?

 

SAMECS Note: I would suggest just changing the permissions on the config_spec file in View storage. This is how we currently prevent this from happening.

 

Answer

New Views

Before creating a new view, ensure the umask setting is set to 022.

This will disable the "write" bit for group and other.

 

Existing Views

For existing views, run fix_prot -chmod 755 to modify the existing permissions.

Note: This utility could possibly take off the "sticky bits" in the view storage .identity directory. Refer to technote 1147171 that discusses how to fix .identity if the sticky bits get unset and need to be repaired.

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

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

34.       How do I – understand the .compiled_spec and config_spec

The ASCII .compiled_spec file is what the view_server and MVFS use to determine which files should be selected.

 

The config_spec file is a flat file that is used as source before the compile, and subsequently when cleartool catcs is issued.

What this means is that the file config_spec is NOT what determines the selection of files in the view.

The .compiled_spec will be regenerated ONLY as the result of a setcs or edcs command.

Problems can arise if the .compiled_spec is not present or if the config_spec is not edited through the appropriate cleartool edcs operation.

Example #1
If for some reason the .compiled_spec file is removed or unreadable due to accidental deletion or some disk error, the setview or startview commands will result in the following error:

mvfs: error: view=view_tag vob=vob_tag no configuration spec set....

What's especially misleading in this case is that cleartool catcs may show a perfectly normal config spec of the view. This is because cleartool catcs merely shows the contents of the config_spec file from view-storage.

To recover from this problem simply execute cleartool setcs -current' which will recompile the config spec and recreate the .compiled_spec, repairing the view trouble.

Example #2
Either the config_spec file was edited directly without a subsequent edcs or a file referenced in the config spec was added as a File-inclusion rule was edited without a subsequent setcs.

When you use File-inclusion rule in a config spec so that a remote file's contents can be used as the config_spec you must recompile the .compiled_spec through use of the
 cleartool setcs -current -tag <viewtag> command each time you make changes to the remote included file.

Review the ClearCase Command Reference Guide on the topic of config_spec (cleartool man config_spec) for more information about config specs and the File-inclusion rule.

35.       How do I - hide an element in a view

The -none rule is very useful in the case where a file that should not be seen within a view and the other methods of hiding the file are not a viable choice.

The following excerpt is taken from the config_spec reference page on the usage of the -none option:

In a dynamic view:


In a snapshot or Web view:

Example Syntax:
element * CHECKEDOUT
element file.txt -none
element * /main/LATEST

36.       How do I - exclude elements from a view

The config spec uses a query language to evaluate which elements to display in a view, thus a config spec can be written to exclude certain elements.

Review the IBM Rational ClearCase Command Reference on the topic of query_language (cleartool man query_language) for more information.

Example 1:

To exclude all elements with the label TEST_LABEL, use the following config spec;


element * CHECKEDOUT                                    
element * "{version(/main/LATEST)&&!version(TEST_LABEL)}"

Note: This config spec will unload the file from a snapshot view, however, the file reference will still appear in the view. The file will now appear in ClearCase Explorer marked as "no version loaded". This is expected behavior.

Example 2:

Another example that would be valid is to avoid newly created branch version zero.

 

element * CHECKEDOUT

element * "{version(.../dev/LATEST)&&!version(.../dev/0)}"

element * /main/LATEST

37.       How do I - exclude branches from a view by using config spec rules

The following shows an example of how you can structure a view's config spec rules to exclude branches from a view.

 

Example:

element * CHECKEDOUT
element * "{!brtype(branch_name)&&version(label_name)}"
element * /main/LATEST

The above example will exclude any elements with "branch_name" and include anything Labeled with "label_name" that are not on "branch_name".

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

38.       How do I - create a config spec to display files with a particular extension

Modifying the config spec to filter on specific file extensions can be done for both snapshot and dynamic views. The example below shows the config spec of a snapshot view.

Note: The load rule is NOT part of the syntax for a dynamic view.

INSTRUCTIONS:

The basic method used to filter on specific file extensions is to use a modified wild card as the pattern (for example *.java). This allows the config spec to filter on the .java name.

To set up a view that will load from multiple VOBs and select .java files in subdirectories, use the following type of config spec:

load \vob1
load \vob2
element * CHECKEDOUT
element -directory * /main/LATEST
element *.java /main/LATEST


To set up a view that will load from multiple VOBs and select .java files only in the root of the VOB, specify the VOB tags individually.

load \vob1
load \vob2
element * CHECKEDOUT
element -directory \vob1 /main/LATEST
element -directory \vob2 /main/LATEST
element *.java /main/LATEST


To load subdirectories of one VOB and only the root directory of the other:

load \vob1
load \vob2
element * CHECKEDOUT
element -directory \vob1\... /main/LATEST
element -directory \vob2 /main/LATEST
element *.java /main/LATEST


Note: The above sample config specs use back slash "\" path structures which are specific to Microsoft® Windows®. Adjust appropriately for UNIX® and Linux® based config specs which require a forward slash "/".

39.       How do I – understand about the limits of the config spec editor

The configuration specification (config spec) editor is a built-in tool used to revise the rules of a ClearCase dynamic or snapshot view.

The known limitations are:


How can you determine the size of you config spec?

Save the query as a text file and read the size as displayed by the operating system.


What happens if the config spec is larger than 128 KB?

An Application error will occur.

 

 

 

Snapshot views

40.       How do I – understand about .unloaded snapshot view files

Why does an IBM® Rational® ClearCase® snapshot view create and maintain a .unloaded directory?

 

Answer

What actions occur when a directory is unloaded?

If a directory is unloaded in a snapshot view, all of the view-private files and directories are copied into a directory named <directory>.unloaded.

Following are the possible actions the snapshot view update tool takes when it unloads a file:

1.     Deleted. The file was deleted from the view. (This is the default action.)

2.     Unavailable. This indicates an error condition. For some reason (possibly due to problems with the network), the update tool can't access the VOB to determine whether to unload the element.

3.     Renamed. A hijacked file has been unloaded (because it is no longer specified by the load rules), but the options for handling hijacked files specify that it be renamed with a .keep extension.

4.     Preserved. A hijacked file has been unloaded (because it is no longer specified by the load rules), but the options for handling hijacked files specify that it be left untouched.

What causes the files to be unloaded?

There are several scenarios that can cause files to be unloaded.

The two main reasons are listed below:

1.     Unloaded files may be caused if the load rules have been edited in the user's snapshot view. This will cause ClearCase to report .unloaded for any files that are specifically 'unloaded' from the snapshot view. This can be observed by looking at the config spec.

2.     Unloaded files can also be caused by an Update being halted prematurely.
The recommended method to alleviate this situation is to run the Update
again and allow it to run to completion.

Under what conditions would a <directory name>.unloaded be created or not created?

These conditions must be met for a directory version to have .unloaded appended after getting unloaded:

That is,

There will be no .unloaded appended to its name.


Refer to
technote 1255163 About the temporary files created by ClearCase for further information about temporary files.

41.       How do I - create a snapshot view from Windows stored on a ClearCase UNIX server using CCFS

Notes:

·         This feature is not available for dynamic views, refer to technote 1123321 for directions on creating and sharing dynamic views in an interop environment.

·         This configuration will only be supported when CCFS is used as the interop solution.

A snapshot view can be created on UNIX or Linux from Windows if the view storage directory is generated using a registered storage location that does not have a global path.

If the cleartool mkview -snapshot command syntax contains a UNC (Universal Naming Convention) path, then the operation will fail.

This is the same functionality used in Rational ClearCase LT® that allows snapshot views to be created across platforms; see technote 1121208 for more details.

Snapshot views cannot be shared between operating systems, even though they can be created across platforms; therefore, views created from Windows are only for use on Windows, see technote 1252575 for more details.

The view creation will apply security to the view based on the Windows user identity mapped onto UNIX.

ClearCase interop requires that all Windows users' usernames and their primary groups have matching usernames and primary groups on UNIX (or Linux) in a Rational ClearCase interop environment; see technote 1146784 for more details.

 

Create a Snapshot View

1.     From UNIX, register the view storage location in the UNIX and Windows regions:

·         cleartool mkstgloc -view -host ccviewserver -hpath /ccstg/views/snapshot.view.stg -ngpath snapshot.view.stg /ccstg/views/snapshot.view.stg

·         cleartool mkstgloc -view -region windows-region -host ccviewserver -hpath /ccstg/views/snapshot.view.stg -ngpath snapshot.view.stg /ccstg/views/snapshot.view.stg

2.     Create a snapshot view from a Windows client using

cleartool mkview -snapshot -tag <tag name> -stgloc <stgloc name> <local snapshot view path name>

Example:

C:\>cleartool mkview -snapshot -tag snap_vu -stgloc snapshot.view.stg c:\Rational\Storage\views\snap_vu


Note: The view can also be created from the GUI, by specifying the storage location in the Advanced View Options of the View Creation Wizard:


3.     The snapshot view will need to have a tag in the UNIX region as well.

cleartool mktag -view -tag <tag name> -region <UNIX region> -ngpath -host <hostname> <snapshot view path name>

Example:

C:\>cleartool mktag -view -tag snap_vu -region unix-region -ngpath -host ccviewserver /ccstg/views/snapshot.view.stg

Related information

About ClearCase Server Storage locations

42.       How do I - remove the read-only attribute from all files loaded in a snapshot view

 

Removing the read only attribute is useful if you want to modify files without checking them out and without saving to a new copy if you modify the loaded file. Keep in mind that once a file is modified in a snapshot view that has not been checked out, you need to be prepared to deal with hijacked files upon view update. Review the Working in Base ClearCase manual for more information about hijacked files.

Using the cleartool find command and the Windows attrib.exe utility will allow you to remove the Read Only attribute from files.

Note:
The attrib.exe command comes standard with all Windows operating systems and is located in the system32 directory.


INSTRUCTIONS:

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

2.     Change directory (cd) to the snapshot view root and into the root of the VOB

Run the cleartool find command (cleartool find . -all) executing the attrib utility on the elements found.

Example:
C:\snapshot_view\VOB>cleartool find . -all -exec "attrib -R \"%CLEARCASE_PN%\""

Note: Errors will be received on elements that are not loaded in the snapshot view and these can be ignored.

43.       How do I - Identify the snapshot view root location

How to determine the location of an IBM® Rational® ClearCase® snapshot view root on Microsoft® Windows® Linux® and UNIX®.

 

Solution

Unless the view was created in the default manner of having view storage directly under the view root, there is currently no command to use which can determine the location.

The cleartool lsview -long command still only lists the view tag and view storage, not the view root.

Change request (RFE) RATLC00606966 has been submitted to address this functionality.


WORKAROUNDS:

UNIX/LINUX & WINDOWS

UNIX/LINUX ONLY

Note: ClearCase operations use information from this file. If this file is deleted or corrupted, the information must be regenerated for each snapshot view that is used. To do so, update the view with either of the following commands:

cleartool update
cleartool update -print


Note: If the permissions on the .ccase_svreg have been modified such that the write permission has been removed for the user, the following error may occur during snapshot view creation:

cleartool: Warning: Unable to register new snapshot view: The file access permissions do not allow the specified action.

The correct permission for the .ccase_svreg file is
 644 (-rw-r--r--).

WINDOWS ONLY

1. The Snapshot view update tool presents a pull-down list of these views.

docview

 

2. Edit View Properties displays the view root path:


docview


3. In ClearCase Explorer, hover over the Snapshot view shortcut to reveal the view root location.

docview


4. A review of the Snapshot view Shortcut Properties will reveal the view root location.

docview

docview


5. The location of the snapshot view root or the workspace is tracked in a registry key on the local machine.

Note: This solution contains information about modifying the system registry. Before making any modifications to the Microsoft® Registry Editor, it is strongly recommended that you make a backup of the existing registry. For more information describing how to back up the registry, refer to the Microsoft Knowledge Base article
http://support.microsoft.com/kb/256986.

[HKEY_CURRENT_USER\Software\Atria\ClearCase\CurrentVersion\Workspaces]

If the workspace has been moved you will see duplicate entries in the registry.
The current workspace will contain a hidden .view file.
This file contains the workspace oid and view uuid. Review
technote 1252064 for more information about the .view file.

44.       How do I - relocate the workspace of a snapshot view

The workspace of a snapshot view is its root directory, which is the physical working directory for manipulating ClearCase data or adding new elements to source control.

Note: A snapshot view also has a storage directory, which is a separate entity and unaffected by this procedure, review technote 1147128 for more details.

Move the view root

1.     Make sure all checkouts have been checked in or canceled (cleartool unco)

2.     Create the new directory (folder) for the snapshot view

3.     Copy or move, at least, the view.dat file to the new location. If possible, you should move the entire workspace directory structure. Otherwise, all the VOB elements will get loaded during the next view update.

Note: If the view.dat is not copied, then it can be regenerated as detailed in
technote 1204161.

4.     Change directory (cd) to the new location and execute a cleartool update -graphical command:



5.     Start the ClearCase Explorer and doing either of the following:

o    Got to View > ; or press Alt-F5

Right-click the view shortcut > select Shortcut Properties > edit the Snapshot Location to point to the new location:

undefined

 

45.       How do I - regenerate the view.dat file in a ClearCase snapshot view

The view.dat file is a read-only text file used to identify which work space directory is related to a given snapshot view.

Refer to the IBM Rational ClearCase Developing Software Manual under the topic of How snapshot views are distinguished from standard directories for further details.


Note: The filename on UNIX and Linux is .view.dat.

This file is created in the top level of the snapshot view's directory, and contains a string similar to:

ws_oid:69d492a190374b0cbcf2357c44d4447c view_uuid:84bc6dfdb01d458d93fb9afee9e5f94c

Note:
ws_oid is the Object Identity of the work space directory and the view_uuid is the Universally Unique ID of the view.

If this file is removed (deleted), then the snapshot view will stop working, and the update will return errors, such as detailed in technote 1209320.

The view.dat can be generated using the ClearCase utility, regen_view_dot_dat.pl which can be run from the view's work space directory. This utility ships with Rational ClearCase and is located in:

 

Regenerating a view.dat file

UNIX and Linux

Perl /opt/rational/clearcase/etc/utils/regen_view_dot_dat.pl [–tag snapshot-view-tag] snapshot-view-path

Example:
Perl /opt/rational/clearcase/etc/utils/regen_view_dot_dat.pl -tag pat_v1.4_cropcircle_sv ~/pat_v1.4_cropcircle_sv


Windows
ccperl C:\Program Files\Rational\ClearCase\etc\utils\regen_view_dot_dat.pl [–tag snapshot-view-tag] snapshot-view-path

Example:
ccperl C:\Program Files\Rational\ClearCase\etc\utils\regen_view_dot_dat.pl -tag pat_v1.4_cropcircle  c:\pat_v1.4_cropcircle


Review the ClearCase 7.0 Developing Software manual on the topic of To regenerate the view.dat file (cleartool man To regenerate the view.dat file) for the corrected documentation.

Japanese Windows environment

Running regen_view_dot_dat.pl may fail with an error because only the English message can be handled correctly in the perl script.

Example of the error message:



ccperl "C:\Program Files\Rational\ClearCase\etc\utils\regen_view_dot_dat.pl" -tag <view-tag-id> <view root directory path>

rgy_view_uuid: "".

Unable to get rgy info for view "<view-tag-id>"

usage: C:/atria/bin/ccperl regen_view_dot_dat.pl [-tag snapshot-view-tag] snapshot-view-pname



The ClearCase message has to be changed to display in English by setting the NLSPATH variable before execution of the perl script. If it is not set before the perl script is executed, the UUID for the snapshot view (rgy_view_uuid) cannot be handled correctly as seen in the above error.


Example:

set NLSPATH=C:\

ccperl "C:\Program Files\Rational\ClearCase\etc\utils\regen_view_dot_dat.pl" -tag <view-tag-id> <view root directory path>

rgy_view_uuid: "3ee2c4f595b04602aae9cadc0a049e27"

creating ".\view.dat".

Known Issue

The steps to regenerate the view.dat file located in IBM Rational ClearCase Developing Software are incorrect for versions 2002.05.00 and 2003.06.00.

During execution of the command syntax an error similar to the following occurs:

Can't open perl script "c:\rational\etc\utils": No such file or directory

This syntax error in the commands for UNIX, Linux and Windows was reported as a documentation defect APAR IC44224.

The product documentation has been corrected for Rational ClearCase 7.0 and later.

 

Related information

Regenerate or replace view storage files
Identify the snapshot view root location

46.       How do I - loaded but missing error after updating a snapshot view

The version of the element has been loaded, but this version has been removed or renamed in that particular view.

Note: Although the examples are Windows centric, the concepts and commands are the same (or very similar) on UNIX and Linux.

Example:

Before:
C:\Snapshot_views\snapshot_vu\test_vob>cleartool ls
test.i@@\main\3                        Rule: \main\LATEST

Deleting the file to simulate removal:

C:\Snapshot_views\snapshot_vu\test_vob>del /f test.i

After:
C:\Snapshot_views\snapshot_vu\test_vob>cleartool ls
test.i@@\main\3 [loaded but missing]   Rule: \main\LATEST

Review the ClearCase Command Reference Guide on the topic of ls (cleartool man ls) for more information on this and other types of common errors seen in a view.

 

Resolving the problem

Option #1:
To copy the missing version back into the view (from a location inside or outside the VOB), use the
cleartool get command.

Note:
This will generate a hijacked file.

Example: Outside the VOB
C:\Snapshot_views\snapshot_vu\test_vob>cleartool ls
test.i@@\main\3 [loaded but missing]   Rule: \main\LATEST

C:\Snapshot_views\snapshot_view\test_vob>cleartool get -to C:\Snapshot_views\snapshot_view\test_vob\test.i C:\temp\test.i

C:\Snapshot_views\snapshot_view\test_vob>cleartool ls

test.i@@\main\3 [hijacked]             Rule: \main\LATEST


Example: Inside the VOB
C:\Snapshot_views\snapshot_vu\test_vob>cleartool ls
test.i@@\main\3 [loaded but missing]   Rule: \main\LATEST

C:\Snapshot_views\snapshot_view\test_vob>cleartool get -to C:\Snapshot_views\snapshot_view\test_vob\test.i test.i@@\main\3

C:\Snapshot_views\snapshot_view\test_vob>cleartool ls

test.i@@\main\3 [hijacked]             Rule: \main\LATEST

Option #2:
Run the
cleartool update command to update the snapshot view, specifying the path name to the missing file.

Example:
C:\Snapshot_views\snapshot_vu\test_vob>cleartool update test.i
Loading "test_vob\test.i" (8 bytes).
Done loading "\test_vob\test.i" (1 objects, copied 0 KB).
Log has been written to "C:\Snapshot_views\snapshot_vu\update.17-Apr-07.
07.52.23.updt".

C:\Snapshot_views\snapshot_view\test_vob>cleartool ls
test.i@@\main\3                        Rule: \main\LATEST

Option #3:
Delete the snapshot view and create a new one. The element will then appear as normal without being in a state of "file loaded but missing".

47.       How do I – understand how ClearCase idenfifies hijacked files

ClearCase stores a loaded file size and last modified time stamp (as reported by the file system clock, which ClearCase uses for timing purposes.). ClearCase updates these values each time you check out a file, check in a file, or load a new version into the view.

ClearCase compares the current size and last modified time stamp of a non-checked-out file with the size and time stamp recorded in the view database. If either value is different from the value in the view database, ClearCase considers the file hijacked.

For example, removing the read-only attribute from a file and modifying that file without it being checked out will cause the file to become hijacked.

 

Review the ClearCase Developing Software manual on the topic of About Handling Hijacked Files for more information.

48.       How do I – understand about snapshot views having a view root and a view storage directory

The information contained in this technote serves as a supplement to the information contained in the IBM Rational ClearCase Administrator's Guide.

Each snapshot view has both a view (root) directory and a view storage directory.

The difference between a snapshot view's root directory and storage directory is:


Note: The view root uses a host’s native file system to hold versions of file and directory elements that have been loaded from a VOB.

When creating a snapshot view you are required to specify a directory for Rational ClearCase to load copies of files and directories, which is the view root. You are also prompted to specify a path for the view configuration and database files to be created; the view storage.

Generally, in full ClearCase, the view root is created on the client host, while the view storage can either be created locally also or on a remote view server.

A collocated snapshot view is when both the view root and view storage directories exist in the same location or path.

Note: When working on a mobile computer, such as a laptop, the view root should be put on the mobile device, while the view storage should be created on a non-mobile view server.

In ClearCase LT, the view root is always on the local ClearCase LT client and the view storage is created on the ClearCase LT server.

The view root is used for working on source controlled and view private data.

Note: This location contains a view.dat file that is created by ClearCase and should not be modified or removed.

The view storage directory is for ClearCase administrative purposes only. Do not modify anything in it.

For every 1,000 elements loaded into the view root, ClearCase uses about 400 KB of disk space for the view storage directory.

49.       How do I – understand the operation view_frz_ok_to_set_spec failed: Permission denied issue

The cleartool update -preview or -print command fails in non- co-located snapshot view with the following error:

%cleartool  update -print
cleartool: Error: Operation "view_frz_ok_to_set_spec" failed: Permission denied.
cleartool: Error: Additional information may be available in the view log on host "host1".
cleartool: Error: Operation "ws_ok_to_load" failed: Permission denied.


One indication of this problem relates to users sharing snapshot views.

Example: User 1 creates the view and User 2 has a problem updating the view.

The umask used to create the snapshot view was too restrictive to share with other users.

Example creating the views (note the permission output for each example):

FIRST USER:
umask 002

%> cleartool mkview -snapshot -tag snap03 -vws /host1/snap03.vws /host1/snap03
Created view.
Host-local path: host1:/host1/snap03.vws
Global path:     /net/host1/host1/snap03.vws
It has the following rights:
User : jdoe : rwx
Group: user     : rwx
Other:          : r-x

Created snapshot view directory "/host1/snap03".


umask 022
%> cleartool  mkview -snapshot -tag snap04 -vws /host1/snap04.vws /host1/snap04
Created view.
Host-local path: host1:/host1/snap04.vws
Global path:     /net/host1/host1/snap04.vws
It has the following rights:
User : jdoe : rwx
Group: user     : r-x
Other:          : r-x

Created snapshot view directory "/host1/snap04".


SECOND USER (accessing the views):

%> cd /host1/snap03  (view created with umask 002)

%> ls -l
total 12
drwxrwxr-x   3 jdoe user         512 Jul 17 11:00 ./
drwxrwxrwx  64 root     other       1536 Jul 17 10:57 ../
-r--r--r--   1 jdoe user          82 Jul 17 10:56 .view.dat
drwxr-xr-x   3 jdoe user         512 Jul 17 11:00 host1/

%> cleartool  update -print
Processing dir "host1/v8".
Processing dir "host1/v8/lost+found".
End dir "host1/v8/lost+found".
...
End dir "host1/v8".
.
Done loading "/host1/v8" (4 objects, copied 0 KB).
Log has been written to "/host1/snap03/preview.17-Jul-02.11:00:39.updt".


%> cd /host1/snap04 (view created with umask 022)

%>ls -l
total 12
drwxr-xr-x   3 jdoe user         512 Jul 17 10:58 ./
drwxrwxrwx  64 root     other       1536 Jul 17 10:57 ../
-r--r--r--   1 jdoe user          82 Jul 17 10:57 .view.dat
drwxr-xr-x   3 jdoe user         512 Jul 17 10:58 host1/

%> cleartool update -print
cleartool: Error: Operation "view_frz_ok_to_set_spec" failed: Permission denied.
cleartool: Error: Additional information may be available in the view log on host "host1".
cleartool: Error: Operation "ws_ok_to_load" failed: Permission denied.


The -print option causes a log file to be written to the view root directory; however, since the permission are too restrictive, the log cannot be written, hence the error.

 

Solution

Ensure the umask is set appropriately when creating "shared" views.

Consult your system administrator or operating system manuals for assistance.

50.       How do I – understand why snapshot views are showing all files as hijacked after moving view to new server

After migrating a snapshot view root and storage directories to a new machine, all files are showing up as hijacked

 

Cause

The snapshot view root directory was moved using the ccopy utility which does not preserve modification times.

 

Resolving the problem

Use xcopy to move the view root directory ccopy to move the view storage directory.

 

 

View private

51.       How do I – deal with <DIR..> names in lsprivate output

What does the odd directory output refer to with the following lsprivate output?

% cleartool lsprivate
/tmp/griffin_tut/20865/Obj
/tmp/griffin_tut/20865/Src
/tmp/griffin_tut/
<DIR-3e2f8eb9.9a1711cf.b08e.08:00:09:78:4a:e5>/.cmake.state
/tmp/griffin_tut/
<DIR-bc6a55d8.9e1311cf.b65e.08:00:09:78:4a:e5>/.cmake.state
/tmp/griffin_tut/20865/Obj/.cmake.state
/tmp/griffin_tut/20865/Obj/Makefile

These pathnames indicate view private files that were in a directory element that was removed (using cleartool rmelem or rmname).

 

Solution

The following command will clean up the reference to this deleted object and move any children to the view's lost+found directory:

cleartool recoverview -dir <DIR> -tag <view-tag>

Example using error from above output:

% cleartool recoverview -dir 3e2f8eb9.9a1711cf.b08e.08:00:09:78:4a:e5 -tag view_1

52.       How do I - remove unreferenced view private files

If your View has view private files that are associated with a VOB that has been removed you will get the following error:

 

cleartool: Warning: VOB is unavailable -- using name: "<Unavailable-VOB-1>".

  If it has been deleted use 'recoverview -force -vob vob-identifier -tag view-tag'

  VOB identifier is 818792cb.6f3311db.95fc.00:02:b3:9e:e7:9d

Last known location of storage is <hostname>:<global pathname to .vbs>

 

To resolve this issue you need to run the following command:

 

      cleartool recoverview –vob 818792cb.6f3311db.95fc.00:02:b3:9e:e7:9d –tag <view tag>

 

      cleartool recoverview -dir uuid -tag <view tag>

53.       How do I – understand the unable to delete a view private file issue

Attempts to delete a view-private file results in the following error:


ClearCase Explorer or Windows Explorer:


Error Deleting File or Folder

Cannot delete {filename}: Cannot find the specified file.
Make sure you specify the correct file and name


Screenshot
undefined


Command Line:

The system cannot find the file specified.


The view-private file has been moved or deleted from the view storage within the .s directory.

The view database is still aware of the file and is out of sync with the source container.

Note: The most common reason of this occurrence is due to Virus Scanning. The Virus Scanner is configured to either move a file suspected of a virus to quarantine or is configured to delete the file.

 

Solution

One solution is to remove and recreate the view.

 

Note: If removal of the view in not an option, then synchronize the view database and the source container using the following procedure.

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

Start the view (cleartool startview <view>), mount the VOB (cleartool mount <VOB>) and cd into the VOB to the location of the view-private file.

Run the mvfsstorage utility to identify the path to the view storage container to which the database has made reference. Review the ClearCase Reference Guide on the topic of mvfsstorage (cleartool man mvfsstorage) for more details.

mvfsstorage <filename>

Example:

M:\dynamic_view\test_vob>mvfsstorage test.txt
E:\views\user\dynamic_view.vws\.s\00010\800000084405bf52test.txt

The output displays the location on disk where the view database believes the file is (and should be) located.

Using this information a file with the correct storage container name can be physically re-created at the location specified to resync the database and storage.

Note: Unless you have a copy of the missing view private file with the actual contents, you will lose all the data in the file. Creating a new file with the name in the view source container will not restore the file contents.

Open Windows Explorer and cd to the view storage path identified by mvfsstorage.

Create a new file with the same name in the storage container as that identified by mvfsstorage.

Example:

The file name identified in the example was
800000084405bf52test.txt.
Create a new text file with that exact name.

Delete the file from the view using any interface (GUI or CLI).#

54.       How do I – understand why a UNIX ls command not reporting elements in view

Attempts to run the UNIX/Linux ls command does not return an expected file.

Example: The file conf.lib is expected.

%>ls
ftam.lib      kernel.lib    stack.lib
confftl1.o    ftir.lib      pkvcfg.o

%>ls -l conf.lib
conf.lib: No such file or directory

%>cleartool ls conf.lib
conf.lib@@/main/CHECKEDOUT from /main/0 [checkedout but removed]


Note: The checkedout but removed comment appended to the cleartool ls output means the element was checked out in this view, but the view-private file was subsequently removed. You may have deleted the file.

 

Cause

If the file was checked out and the element's view private file removed, ClearCase commands (such as cleartool ls) can still view the file since the reference is stored in the database; however, since the view-private was removed from the file system, operating system commands will fail to see the file.

 

Resolving the problem

Uncheckout the file.

%>cleartool unco conf.lib
cleartool: Warning: This uncheckout left only version zero on branch
"/main".
Checkout cancelled for "conf.lib". "

55.       How do I - restore a view-private file from backup

DYNAMIC VIEW:

Note: The view storage directory (*.vws) needs to be backed up for dynamic views as this is where the file(s) will be recovered from. If you know the name of the view private file, you can put the backed up .vws into a temporary directory. Then cd into <view-path>.vws/.s of that directory and do a find command ex: find . -name '*foo.c*' (providing the name of the file you want to recover).

To recover a view private file for a dynamic view, use the mvfsstorage command to find the path of the view private file (as it is not intuitive to locate) and replace the file with the back up copy:

Find the file and cat it and "cut and paste" it into the working view.


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

1.     Open a command prompt, set into the view and cd into the VOB where the view private file resides.

2.     Run mvfsstorage <file>

Example:

M:\test_view\my_test_vob>cleartool ls
test_project@@\main\1         Rule: \main\LATEST
test.txt

M:\test_view\my_test_vob>mvfsstorage test.txt
E:\views\test_view.vws\.s\00010\80000019422db43btest.txt


Note: The mvfsstorage command resides in the
<cchome>/etc directory on UNIX and Linux and must be run from that path. On Windows, the mvfsstorage command resides in the <cchome>/bin directory.

3.     Navigate to the location of the file within the view storage directory of the backup and copy the file with the same name.

4.     Navigate to the location of the file within the view storage directory of the active dynamic view and delete the corrupted file(s).

5.     Replace the new file from the backup into that directory with the same name from the mvfsstorage output.

 

SNAPSHOT VIEW:

Note: The view root (location where the files are loaded) must be backed up for snapshot views as this is where the file(s) will be recovered from.

To recover a view private file for a snapshot view, find the copy of the view private file in the backup archive and replace the file in the active view with the copy (just like any normal operating system file restore.

Problems and Issues

56.       How do I – understand that running du -sk in a ClearCase view reports wrong size on Linux

If running du -sk on Linux in a ClearCase view the size reported will show approximately twice the size of the actual size of disk usage.

 

Cause

du" on Linux (and Unix) will report the disk usage.

The switch 's' reports only the total sum for each of the specified files. The k switch reports the files sizes in units of 1024 bytes, rather than the default 512-byte units. If running du -sk in a ClearCase view the reported size will be wrong.


This issue has been identified as a product defect under APAR PK65529.

 

Resolving the problem

Defect APAR PK65529 has been resolved in ClearCase 7.0.0.8 and 7.0.1.7.

57.       How do I – understand that removing a view may cause ClearCase Explorer to crash with a memory reference error or an error "The parameter is incorrect"

 

If you work in a view in ClearCase Explorer and then later remove the same view, ClearCase Explorer may crash with a memory reference error in ClearCase versions 7.0.1.3 Ifix01 and 7.0.1.4. You will receive the error "The parameter is incorrect."

 

Cause

This issue has been identified as a product defect under APAR PK82554.

 

Resolving the problem

There is currently no resolution for this defect.

 

WORKAROUND

To resolve the issue immediately, you will need to remove ClearCase Explorer in the Windows registry:

 

REGISTRY EDITS:

This solution contains information about modifying the system registry. Before making any modifications to the Microsoft® Registry Editor, it is strongly recommended that you make a backup of the existing registry. For more information describing how to back up the registry, refer to the Microsoft Knowledge Base article 256986 at http://support.microsoft.com/kb/256986.

1.     Go to Start==>Run and type regedt32.

2.     In the registry, open HKEY_CURRENT_USER\Software\Atria\ClearCase\CurrentVersion

3.     Right click on ClearCase Explorer and select Delete

This will allow you to open ClearCase Explorer.

Contact IBM Rational Client Support if you wish to request a testfix for the version of ClearCase on your system.

58.       How do I – understand the issue “Unable to start ClearCase which is reporting error: trouble mounting the view root”

 

Attempts to start ClearCase results in this error:

trouble mounting the view root 16:29

 

Cause

The error is a result of a corrupt .specdev file in /view .

 

Resolving the problem

The .specdev file in /view needs to be rebuilt.

Refer to technote 1135104 About the .specdev file in /view directory for information about rebuilding the .specdev file. However; if this does not resolve the issue, you may need to rebuild the .specdev by uninstalling and reinstalling ClearCase (refer to technote 1259627, if needed)

59.       How do I – understand the “rgy_check: Error: Two View objects have the same pathname on a server” issue

Running rgy_check -views is reporting the following error:

rgy_check: Error: Two View objects have the same pathname on a server.
First object:
-hostname = "integ"
-local_path = "/user/integ/.views/cspatch.vws"
-view_uuid = "0f12a312.75e511d0.a6a1.00:01:55:42:fc:96"
This object:
-hostname = "integ"
-local_path = "/user/integ/.views/cspatch.vws"
-view_uuid = "4422a476.75e511d0.a6a2.00:01:55:42:fc:96"


rgy_check: Error: A view tag duplicates another view's global pathname in region smnos.

Similar errors may be reported if you are running rgy_check with the -vobs option.

 

Cause

The error message indicates that two view tags are assigned to the same view's physical storage directory which is illegal in ClearCase. Only one view tag can be given for a view's physical storage directory within a single region.

First tag:
-tag = "CS_PATH"
-hostname = "integ"
-global_path = "/usrx/sv1/integ/.views/cspatch.vws"
-region = "smnos"
-view_uuid = "0f12a312.75e511d0.a6a1.00:01:55:42:fc:96"

Second tag:
-tag = "cspatch"
-hostname = "integ"
-global_path = "/usrx/sv1/integ/.views/cspatch.vws"
-region = "smnos"
-view_uuid = "4422a476.75e511d0.a6a2.00:01:55:42:fc:96"

How did this happen?

This usually happens when there is a process hanging around for a particular view which wasn't removed the proper way. When the user then issues a cleartool mkview command with the same name as the view that was improperly removed, a second view tag entry with a different uuid in the same region is inadvertently created.

 

Resolving the problem

In order to resolve the errors you need to unregister the view and remove the extra view tag.

1.     Issue a cleartool unregister -view -uuid <view-uuid> passing the uuid of the view.

Example:
cleartool unregister -view -uuid 4422a476.75e511d0.a6a2.00:01:55:42:fc:96

Remove the additional view tag:

Example:
cleartool rmtag -view cspatch

60.       How do I – understand that “Adjusting the MVFS cache size when ClearCase is running may cause a kernel panic”

Adjusting the MVFS cache size while ClearCase is running causes a kernel panic.

 

Cause

Defect APAR PK41017 has been opened to investigate this issue.

 

Diagnosing the problem

The backtraces may show the following:

> ::cpuinfo
ID ADDR     FLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD           PROC
3 1041bc00  1d    1    0  -1   no    no t-0    000002a10001fd20 (idle)
0 04baea98  1d    0    0  11  yes    no t-6    000003001063bca0 perl
1 04d39520  1d    0    0   0   no    no t-0    0000030023db5760 perl
2 04d38020  1b    1    0   0  yes    no t-0    000003001ee47c40 perl


> 000003001063bca0::findstack
stack pointer for thread 3001063bca0: 2a105816a31
[ 000002a105816a31 panic_idle+0x1c() ]
 000002a105816ae1 prom_rtt()
 000002a105816c31 mvfs_dnclist_init+0xd8()
 000002a105816ce1 mvfs_dnc_setcaches+0x2ec()
 000002a105816db1 mvfs_set_cache_sizes+0x64()
 000002a105816ec1 mvfs_mioctl+0xa48()
 000002a105817001 mvfs_ioctlv_subr+0x174()
 000002a1058170e1 mfs_ioctlv+0x20()
 000002a1058171a1 ioctl+0x1e4()
 000002a1058172f1 syscall_trap32+0xa8()

> 000003001ee47c40::findstack
stack pointer for thread 3001ee47c40: 2a10162a371
 000002a10162a421 die+0xa4()
 000002a10162a501 trap+0x900()
 000002a10162a641 sfmmu_tsb_miss+0x66c()
 000002a10162a761 prom_rtt()
 000002a10162a8b1 mvfs_get_urdir+4()
 000002a10162a961 mvfs_rvclookup+0x1bc()
 000002a10162aa41 mfs_bindroot+0x44()
 000002a10162ab21 mvfs_lookup_ctx+0x80c()
 000002a10162ac11 mfs_lookup+0x24()
 000002a10162acd1 lookuppnvp+0x2e8()
 000002a10162aed1 lookuppn+0x108()
 000002a10162af91 lookupname+0xe8()
 000002a10162b0b1 vn_open+0x100()
 000002a10162b221 copen+0x94()
 000002a10162b2f1 syscall_trap32+0xa8()

 

Resolving the problem

Refrain from modifying the cache size while ClearCase is being heavily used.

There is no fix currently available for this defect.

WORKAROUND:

Change the scaling factor when the system is quiet, and then reboot.

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

Note: Attempts to only stop ClearCase to adjust the cache will fail. You need to adjust the cache while ClearCase is idle and started and then reboot the server to take affect.

Example Error:

# /opt/rational/clearcase/etc/clearcase stop

# cleartool setcache -mvfs -persistent -scalefactor 4
cleartool: Error: Operation "view_mfs_set_cache_sizes (current sizes)" failed: not a ClearCase object.
cleartool: Error: Operation "view_mfs_set_cache_states (current sizes)" failed: not a ClearCase object.
cleartool: Warning: Some or all of the parameters you are setting will not take effect until you restart ClearCase.

# /opt/rational/clearcase/etc/clearcase start
ClearCase daemons: albd_server lockmgr -q 1024 -u 256 -f 256
Loading MVFS ...
Mounting public VOBs...

# cleartool setcache -mvfs -persistent -scalefactor 4
cleartool: Warning: Some or all of the parameters you are setting will not take effect until you restart ClearCase.

61.       How do I - regenerate the view.dat file

The steps to regenerate the view.dat file located in IBM Rational ClearCase Developing Software are incorrect for versions 2002.05.00 and 2003.06.00.

During execution of the command syntax an error similar to the following occurs:

Can't open perl script "c:\rational\etc\utils": No such file or directory

There is a syntax error in the commands for UNIX, Linux and Windows.

This was reported as a documentation defect,
APAR IC44224, and has been corrected in Rational ClearCase 7.0.

 

Solution

The view.dat file is a read-only text file used to identify which work space directory is related to a given snapshot view.

Note: The filename on UNIX and Linux is .view.dat.

This file is created in the top level of the snapshot view's directory, and contains a string similar to:

ws_oid:69d492a190374b0cbcf2357c44d4447c view_uuid:84bc6dfdb01d458d93fb9afee9e5f94c

Note:
ws_oid is the Object IDentity of the work space directory and the view_uuid is the Universally Unique ID of the view.

If this file is removed (deleted), then the snapshot view will stop working, and the update will return errors, such as detailed in
technote 1209320.

The view.dat can be generated using the ClearCase utility, regen_view_dot_dat.pl. This utility ships with Rational ClearCase and is located in:

Regenerating a view.dat file

UNIX and Linux

Perl /opt/rational/clearcase/etc/utils/regen_view_dot_dat.pl [ –tag snapshot-view-tag ] snapshot-view-path


Example:

Perl /opt/rational/clearcase/etc/utils/regen_view_dot_dat.pl -tag pat_v1.4_cropcircle_sv ~/pat_v1.4_cropcircle_sv


Windows

C:\Program Files\Rational\ClearCase\etc\utils\regen_view_dot_dat.pl [ –tag snapshot-view-tag ] snapshot-view-path


Example:

ccperl C:\Program Files\Rational\ClearCase\etc\utils\regen_view_dot_dat.pl -tag pat_v1.4_cropcircle  c:\pat_v1.4_cropcircle

62.       How do I - regenerating or replacing view storage files

The view storage directory contains a number of control files in addition to the database and view private storage area.

The below information addresses which of these control files (if missing), Rational ClearCase will regenerate automatically, and which of these files can be recreated manually.

Files that are regenerated automatically when the view is restarted:

 

Files that can be regenerated with ClearCase commands:

 

Files that can be manually replaced by making a new view on the same machine as the same user, and copying the affected file(s) to the view storage:

Files that cannot be replaced:

63.       How do I - remove checked-out references of a view from a VOB

how to remove IBM® Rational® ClearCase® checkout references that are cataloged in the VOB database after a view is removed or becomes inaccessible using the cleartool rmview -uuid command on Microsoft® Windows®, UNIX®, or Linux®.

 

Cause

Attempts to perform a checkout result in the following error:


%cleartool co foo.c
cleartool: Error: Element "foo.c" is already checked out to view "<no-tag-in-region>".


Attempts to uncheckout a file result in the following error:


%cleartool unco foo.c
"Cannot_generate_name_for_checkout_in_view:.."


The checkout fails because the file is already checked out reserved to a view that was either removed or is no longer accessible on the network.

If a view has become inaccessible or was deleted by mistake and the VOB database still holds references to the checkouts you will need to remove the reference from the VOB database in order to checkout the file from a different view.

Note: Review technote 1129391 if the view still exists and you do not wish to uncheckout the element (potentially losing the changes made).

 

Solution

Having checkout(s) to a view that is no longer available or accessible is very common.

Here are some steps on how to remove the references in the VOB database.

Note: Only run this procedure if the data contained in the view (the checkouts) are no longer needed or if the view no longer exists. This operation performs an uncheckout in the VOB database for all elements that were related to the view. If a view still exists and you use the procedure below to delete records relating to it from any VOB, make sure that the view is removed immediately.

 

MULTISITE CONSIDERATIONS:
If removing the view checkout references from a replicated VOB, the rmview command should be run at the site where the view checkouts were originally performed.

See
technote 1124700 if you are running 2002.05.00 and have a problem removing references to the VOB.

Refer to the rmview section of the ClearCase Command Reference Guide for additional information about the usage of the rmview command.

 

PROCEDURE:

1. First you need to determine what the UUID is of the old view.

a. COMMAND TO RUN IF THE VIEW EXISTS:


From the command line you will need to run
cleartool lsview -long and find the view and copy its uuid number. Example:

cleartool lsview -long TEST
Tag: TEST
  Global path: \\MYHOST\VIEW\TEST.vws
  Server host: MYHOST
  Region: Your_Region
  Active: YES
  View tag uuid:fa7fc590.42f34d53.ae68.b6:30:f5:30:c5:a4
Text mode: unix
View on host: Your_Host
View server access path: C:\VIEW\TEST.vws
View uuid: fa7fc590.42f34d53.ae68.b6:30:f5:30:c5:a4
View owner: MYDOMAIN\user1


b. COMMAND TO RUN IF THE VIEW HAS BEEN REMOVED:


From the command line you will need to run
cleartool describe -l vob:\<vobname> and find the view and copy its uuid number. Example:

cleartool describe -long vob:\baseccvob
versioned object base "\baseccvob"
  created 04-Oct-04.16:48:26 by user1.group1@MYHOST
  VOB family feature level: 4
  VOB storage host:pathname "MYHOST:C:\CC_Store\vob\baseccvob.vbs"
  VOB storage global pathname "\\MYHOST\cc\vob\baseccvob.vbs"
  database schema version: 54
  VOB ownership:
    owner MYDOMAIN\user1
    group MYDOMAIN\group1
  VOB holds objects from the following views:
    MYHOST:C:\VIEW\TEST.vws [uuid a7fc590.42f34d53.ae68.b6:30:f5:30:c5:a4]
  Attributes:
    FeatureLevel = 4
  Hyperlinks:
    AdminVOB@687@\baseccvob -> vob:\proj_1

 

2. The next step is to remove all the references to the VOB (which will perform the uncheckout).

COMMAND TO RUN:


From the command line you will need to run
cleartool rmview -uuid <long uuid #> -avobs to remove all the checkedout references from all VOBs in that region.

Example:

%cleartool rmview -uuid fa7fc590.42f34d53.ae68.b6:30:f5:30:c5:a4  -avobs

Removed references to view "fa7fc590.42f34d53.ae68.b6:30:f5:30:c5:a4" from VOB "\VOB1".
Removed references to view "fa7fc590.42f34d53.ae68.b6:30:f5:30:c5:a4" from VOB "\VOB2".
Removed references to view "fa7fc590.42f34d53.ae68.b6:30:f5:30:c5:a4" from VOB "\VOB3".
Removed references to view "fa7fc590.42f34d53.ae68.b6:30:f5:30:c5:a4" from VOB "\VOB4".


3. The last step is to verify if the references have been removed from the VOB.


Use the command invocation from 1b (
cleartool describe -l vob:\<vobname>) to ensure the checkout are gone.

If the references have not been removed, follow the instructions in technote 1146797.

Note: If a directory has been unchecked out, then all new elements created when it was checked out are no longer referenced by that directory. Consequently, they were all moved to the lost+found directory.

To restore these files from the lost+found directory, please refer to technote 1120317.

64.       How do I – understand what to do when cleartool rmview -uuid does not remove view references

In ClearCase 2002.05.00, there was a defect logged against certain scenarios pertaining to Derived Objects in replicated VOBs which are known to cause this problem. See technote 1124700 for more information.

In ClearCase 7.0, defect APAR PK38852, has been submitted to address the concern of rmview -uuid not removing all the references from the view. This behavior has been reported to occur when issuing cleartool rmview with or without the -uuid switch.


Example error related to this symptom:

Attempts to remove a view results in the following error:

%>cleartool rmview -force -vob /vobs/test -uuid c05adaeb.45aa11da.92b5.00:01:80:f7:8d:2c

 

cleartool: Warning: Looking for a broken Config Record that might still have some references to the view. This might take a long time depending of the number of derived objects and configuration records within the VOB.
As a progress indicator, the total number of processed derived objects will be reported for approximately each 200 processed derived objects.
cleartool: Error: Some view references are still left in the VOB.
cleartool: Error: Trouble removing references to view

 

Solution

There is currently no solution for this defect. Review the below workarounds and use the one most appropriate for the situation you are trying to address.

To prevent this issue from occurring, use the graphical remove view functionality, instead of the command line interface as this issue is only known to occur with cleartool rmview with or without the -uuid switch.

 

WORKAROUND 1:

If after running the instructions described in technote 1122515 the VOB still holds checkouts to your dynamic views, attempt to run recoverview on the referenced view as instructed in technote 1127003.

WORKAROUND 2:

If checkout/checkin to the deleted view is blocking your work, the existing checkout can be converted to UNRESERVED by the element owner or VOB owner by using the following command:

cleartool unreserve -view <hostname:view-storage-dir-pname> <element-pname>

Review technote 1129391 for more information.

 

WORKAROUND 3:

If the above fails or the referenced view has already been removed, contact IBM Rational Client Support.

When these incidents occur, the only solution is to have our engineering team create a tool that will manually reset the reference flags in the database.


To expedite your request, provide the following information before contacting support:

1.     The command line output of the rmview -uuid BEFORE and AFTER it was issued.

a.     cleartool lsview <view name>

b.     cleartool describe -long vob:\<vobtag>

c.     cleartool rmview -uuid <uuid>

d.     cleartool describe -long vob:\<vobtag>

Note: This is to make sure the command was run correctly and that there were no meaningful errors.

2.     Is the VOB which has this referenced checkout replicated? If so,

a.     Do the other sites see the referenced checkout?

b.     Are they able to remove the reference using "rmview -uuid"?

3.     Provide the following information for EACH replicated VOB that has this problem:

a.     ClearCase version

b.     Database schema version

Operating System

If it is determined that a tool is in fact warranted, it will be issued by our technical support staff with detailed instructions on its use.

IMPORTANT: If issued, please do not run the tool on ANY other VOB after its initial use. The tool is created on a case by case basis for a single VOB database.

65.       How do I – understand the trouble removing view references from a replicated VOB using rmview -uuid -vob command

After running the IBM® Rational® ClearCase® describe -long command, several VOB holds objects from the following views messages are displayed even after using the cleartool rmview -uuid command to remove the references.

 

Cause

Review technote 1122515 for more information on the rmview -uuid command and it usage.

The objects being referred to are most likely derived objects (DOs).

When a DO is accessed by a view, two references are made in the VOB:

One reference is specific to the DO

The other is a general reference to the view.


If the view is improperly removed in this situation, the above scenario can occur.

The DO-specific reference to the view can be removed with the cleartool rmview -uuid command, but the other general reference cannot (even though the VOB is no longer really holding a reference to that view).

Defect RATLC00588487 has been logged against this behavior.

 

Solution

This defect has been fixed in the following 2002.05.00 ClearCase patches.

Microsoft® Windows®

clearcase_p2002.05.00.NT-15

Linux and UNIX®

clearcase_p2002.05.00-15

The patch above corrects a defect that could cause config records to be lost in a view. This could also cause internal errors when examining hierarchical config records (diffcr -flat or diffcr -recurse), and could also cause rmview to fail with an internal error when attempting to remove views that had lost config records.

If the checkout/checkin to the deleted view is blocking your work, the existing checkout can be converted to UNRESERVED by the element owner or VOB owner using the following command:

cleartool unreserve -view <hostname:view-storage-dir-pname> <element-pname>

66.       How do I – understand about running recoverview when referenced checkouts still exist in a VOB even after running cleartool rmview -uuid

After running cleartool rmview -uuid in an IBM® Rational® ClearCase® VOB, checkout references to the view are still appearing. This technote explains how to synchronize the view with the VOB in order to resolve this problem.

 

Solution

Use the cleartool recoverview command to try to resynchronize the view and the VOB(s) if the steps outlined in technote 1122515 do not yield positive results.

The recoverview command repairs a view database and the associated private storage area of a dynamic view. (A snapshot view has no private storage in the same sense as a dynamic view has which is why recoverview will not work on a snapshot view.) Typically, you use this command after a system crash or similar mishap (specifically related to the rmview -uuid scenario).

1. Open a command prompt

2. Issue the following recoverview command:

cleartool recoverview -synchronize -tag <viewtag> -- if there are still checkout references in multiple VOBs.

cleartool recoverview -synchronize -vob <vobtag> -tag <viewtag> -- if there are still checkout references in one VOB.


This command will try and resynchronize the view and the VOB to the status of the check outs.

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

IMPORTANT NOTE: Before proceeding, please understand that there is the possibility of losing view private files in said view as noted in the Reference Guide entry for recoverview.

If the recoverview fails to resynchronize said view to the VOB, removing and recreating the view will be necessary.

If the references are still in the VOB after running recoverview, see technote 1146797.

67.       How do I – Remove checkedout references from a view that no longer exists

Attempts to perform a checkout may result in the following error:


%cleartool co foo.c
cleartool: Error: Element "foo.c" is already checked out to view "<no-tag-in-region>".


Or when attempting an uncheckout a file:


%cleartool unco foo.c
"Cannot_generate_name_for_checkout_in_view:.."


The checkout fails because the file is already checked out reserved to a view that was removed.

If a view has become inaccessible or was deleted by mistake and the VOB database still holds references to the checkouts you will need to remove the reference from the VOB database in order to checkout the file from a different view.

Note: Review technote 1129391 if the view still exists and you do not wish to uncheckout the element (potentially losing the changes made).

 

Solution

Having checkout(s) to a view that is no longer available is very common.

Here are some steps on how to remove the references in the VOB database.

Note: Only run this procedure if the data contained in the view (the checkouts) are no longer needed or if the view no longer exists. This operation performs an uncheckout in the VOB database for all elements that were related to the view. If a view still exists and you use the procedure below to delete records relating to it from any VOB, make sure that the view is removed immediately.

MULTISITE CONSIDERATIONS:
If removing the view checkout references from a replicated VOB, the rmview command should be run at the site where the view checkouts were originally performed.

See
technote 1124700 if you are running 2002.05.00 and have a problem removing references to the VOB.

Refer to the rmview section of the ClearCase Command Reference Guide for additional information about the usage of the rmview command.

 

PROCEDURE:

1. First you need to determine what the UUID is of the old view.

a. COMMAND TO RUN IF THE VIEW EXISTS:


From the command line you will need to run
cleartool lsview -long and find the view and copy its uuid number. Example:

cleartool lsview -long TEST
Tag: TEST
  Global path: \\MYHOST\VIEW\TEST.vws
  Server host: MYHOST
  Region: Your_Region
  Active: YES
  View tag uuid:fa7fc590.42f34d53.ae68.b6:30:f5:30:c5:a4
Text mode: unix
View on host: Your_Host
View server access path: C:\VIEW\TEST.vws
View uuid: fa7fc590.42f34d53.ae68.b6:30:f5:30:c5:a4
View owner: MYDOMAIN\user1


b. COMMAND TO RUN IF THE VIEW HAS BEEN REMOVED:


From the command line you will need to run
cleartool describe -l vob:\<vobname> and find the view and copy its uuid number. Example:

cleartool describe -long vob:\baseccvob
versioned object base "\baseccvob"
  created 04-Oct-04.16:48:26 by user1.group1@MYHOST
  VOB family feature level: 4
  VOB storage host:pathname "MYHOST:C:\CC_Store\vob\baseccvob.vbs"
  VOB storage global pathname "\\MYHOST\cc\vob\baseccvob.vbs"
  database schema version: 54
  VOB ownership:
    owner MYDOMAIN\user1
    group MYDOMAIN\group1
  VOB holds objects from the following views:
    MYHOST:C:\VIEW\TEST.vws [uuid a7fc590.42f34d53.ae68.b6:30:f5:30:c5:a4]
  Attributes:
    FeatureLevel = 4
  Hyperlinks:
    AdminVOB@687@\baseccvob -> vob:\proj_1

 

2. The next step is to remove all the references to the VOB (which will perform the uncheckout).

 

COMMAND TO RUN:

From the command line you will need to run cleartool rmview -uuid <long uuid #> -avobs to remove all the checkedout references from all VOBs in that region.

Example:

%cleartool rmview -uuid fa7fc590.42f34d53.ae68.b6:30:f5:30:c5:a4  -avobs

Removed references to view "fa7fc590.42f34d53.ae68.b6:30:f5:30:c5:a4" from VOB "\VOB1".
Removed references to view "fa7fc590.42f34d53.ae68.b6:30:f5:30:c5:a4" from VOB "\VOB2".
Removed references to view "fa7fc590.42f34d53.ae68.b6:30:f5:30:c5:a4" from VOB "\VOB3".
Removed references to view "fa7fc590.42f34d53.ae68.b6:30:f5:30:c5:a4" from VOB "\VOB4".


3. The last step is to verify if the references have been removed from the VOB.


Use the command invocation from 1b (
cleartool describe -l vob:\<vobname>) to ensure the checkout are gone.

If the references have not been removed, follow the instructions in technote 1146797.

Note: If a directory has been unchecked out, then all new elements created when it was checked out are no longer referenced by that directory. Consequently, they were all moved to the lost+found directory.

To restore these files from the lost+found directory, please refer to technote 1120317.

68.       How do I – resolve operation "view_ws_is_ws_view" failed: view storage directory or control files unavailable

Views stored on a UNIX/Linux server cannot be set (cleartool setview) without resulting in the following error:

cleartool: Error: Operation "view_ws_is_ws_view" failed: view storage directory or control files unavailable --
additional information may be present in the view server host's view log.
Starting myview view...

Note: An entry similar to that above appears in the view_log as well.

 

Cause

There are multiple causes related to this error:

There may be an application conflicting with the ClearCase view_server process (such as Data Replication Software).

 

Diagnosing the problem

1.     UNIX & LINUX ONLY: If a view was moved from one system to another, check whether, on the new file system, the view is mounted to allow setuid operation or not. This can be tested by listing the mount options for the file system (using the UNIX mount command, with no options). If the setuid operation is disallowed it will be seen as a "nosuid" flag in the mount options for that file system.

For example, on HP-UX, the following file system has setuid disallowed:
% mount
/tmp on /dev/vg00/lvol4 nosuid on Fri May 19 09:20:25 2002


If the setuid is disallowed it must be turned on for that file system. This involves remounting it or a choosing a different location for the view storage.

For more details on changing UNIX mount options, review the UNIX man pages for 'mount' and mount_<fstype>' where <fstype> is 'hfs', 'nfs','jfs'.

2.     UNIX & LINUX ONLY: Recreate the uid and or gid files and set the appropriate setuid bits.
The appropriate setuid bits for .identity file should be as the following:

-r----s--- gid
-r-S------ uid


If the setuid bits entry was set incorrectly, it can be fixed by running a UNIX chmod command:

% chmod 4400 uid
% chmod 2410 gid


Refer to
technote 1204876 Setting the UNIX setuid and setgid bits in a ClearCase VOB or view storage directory for further information.

3.      

4.     WINDOWS, LINUX and UNIX: Run the cleartool recoverview command to try and restore the view to its normal state. Review the ClearCase Reference Guide on the topic of recoverview (cleartool man recoverview) for more information.

5.     WINDOWS, LINUX and UNIX: Reprotect the view storage by running the fix_prot utility. Refer to technote 1142606 for more information on how to properly run the ClearCase fix_prot utility.

WINDOWS ONLY: Remove any applications conflicting with ClearCase processes. One such application is WANSync by XOsoft Corp. WANSync is a Data Replication Software Suite that replicates data from one server to another for Data Recovery.

 

Resolving the problem

If there is a stale view server process left over from a view which is not currently set, you can kill the view_server process and try setting the view.

 

WORKAROUND:

If either steps 3 or 4 above do not help and the view still gives errors, then there is no resolution to repair the existing view and it is recommended to remove the view and recreate it.

There may be files in the view that must be recovered or checked in before removing the view. The following steps may provide a temporary solution to perform the necessary cleanup operations to prevent loosing any data when the view is removed:

1.     Find a known good view and cd to the view storage directory (.vws)

2.     Copy the .access_info file from the good view into the corrupt view.

Try to set into the view and perform the necessary operations (copy view private or checkin elements) before removing the view.

Note: If this workaround does not allow you to set into the view, try repeating step 4 under Diagnosing the problem. If that still fails, the view is unusable and can only be restored from backup (if applicable) or removed.

69.       How do I – understand the checked out version, but could not copy data - permission denied issue

Why attempts to checkout an IBM® Rational® ClearCase® element results in the error Checked out version, but could not copy data in view permission denied..

 

Checkout fails with:

Checked out version, but could not copy data to "M:\vob\dir\file.doc" in view permission denied.  Correct the condition, then uncheckout and re-checkout the element.

There are multiple reasons for this error:

1.     The file is located inside a directory. During checkout ClearCase is copying the file from the cleartext pool into that directory. This means that the user or the group needs write permissions on the parent directory of the file that is being checkedout. So if for example the directory permissions were 755, the only user who could checkout files in the directory would be the directory owner (as the owner is granted write permissions).

2.     Verify if the file can be read from with in the VOB while checked-in. If the file cannot be read, it cannot be copied.

3.     If the file can be read, it means that the VOB storage permissions are OK.

4.     If the file cannot be read, it means that the VOB storage permissions are problematic.

Note: If the permissions were not OK, this would cause an MVFS error to be seen from a dynamic view as well. Also when the view storage permissions or the share permissions are insufficient, you would normally see an Access Denied message and not Permission Denied. Being able to copy the file into the view requires that the correct write permissions are applied to the view storage directory.

 

Solution

If the issue is related to permissions on the directory element, run the cleartool protect command to add the correct privledges. Review the ClearCase Command Reference Guide on the topic of protect (cleartool man protect) for more information.

If the issue is related to the view staorage area, try correcting the protections on the view storage directory using operating system commands and functionality. It may also be necessary to use fix_prot to correct the protections on the view as detailed in technote 1142606. (In previous RSS feed)

WORKAROUND:

If the above does not resolve the problem, then a new view storage area could be created. You can try moving the view to the new location, refer to technote 1129835 for guidance.

70.       How do I – understand the dross-device link error during view creation issue

Attempts to create a view results in the following error:

cleartool mkview -tag build_vw -host host1 -gpath
/net/host1/export/views/build_vw.vws -hpath
/net/host1/export/views/build_vw.vws
/net/host1/export/views/build_vw.vws

cleartool: Error: Unable to rename "/tmp/.view20087" to "/net/host1/export/views/build_vw.vws/.view": Cross-device link.
cleartool: Error: Unable to create view "/net/host1/export/views/build_vw.vws


This error can occur if you set your EUID (EUID expands to the Effective User Identifier, of the current user or process, initialized at shell startup) to be different from your
UID so inorder to have the view be owned by a specific user.


Example:

The Administrator (uid = 100) wants to create a view for user Joe (uid = 200).

When the EUID of Administrator is set to 200, the expectation is that ClearCase will create the view as if Joe owned it.

This will not work with ClearCase. Your UID is required to create the view, not the EUID.

71.       How do I – recover from a setwork operation failed in view error after VOBs moved to a new server

Why do attempts to perform an IBM® Rational® ClearCase® UCM rebase operation after a VOB has been moved to a new server results in the error Merge Manger: Error: Setwork operation failed in view

 

Cause

During a rebase operation, the following errors occur:

Merge Manger: Error: Setwork operation failed in view. More information
might be available in view_log on host: view_host
Merge Manager: Error: Unable to set integration activity
"rebase.project.20040217.155703".
Merge Manger: Error: Unable to set integration activity.
Merge Manager: Error: Unable to perform integration.

The view log displays the following warning:

view_log:
17//02//04 03:57:05 PM view_server(14516): Warning: VOB 5d0632d0.fdbd11d6.89d5.00:01:80:a8:03:87 moved from host1:/vobstore/pvob.vbs

17//02//04 03:57:05 PM view_server(14516): Error: view_setwork_cleanup failed: Stale NFS file handle


The VOB that the development view accessed was moved and the view database has not been updated to reflect the change.

Solution


Check out any file in the development view then undo the checkout. This should update the view database with the new VOB location and allow.

72.       How do I – deal with the error: ./identity/uid is not set-id

Attempts to access a VOB, such as cat a file, or set to a view, results in the following error:


./identity/uid is not set-id


The vob_log contains an error like:


Error: ./identity/uid is not set-id".


Note:
This error will also be found in the view_log and the albd_log, if a setview command fails.

The permissions on the VOB's or view's .identity directory files are incorrect.

 

 

Solution

For VOBs:

Change directory (cd) to the VOB storage area's .identity subdirectory and execute the following commands.

1.     cd /net/hostname/vobstore/testvob.vbs

2.     chmod 4400 uid

3.     chmod 2410 gid

4.     chmod 2410 group.xxx (where xxx is an integer)

5.