How are the .copyarea.dat and .copyarea.db files are used in an IBM® Rational® ClearCase® Remote Client (CCRC) or ClearCase Web (CCWeb) view.
Each CCRC or CCWeb view root directory (the directory tree where the files from the VOB are downloaded into the local view workspace) contains a .copyarea.dat and a .copyarea.db file. Below is a brief explanation of how these files are used.
.COPYAREA.DAT
The .copyarea.dat file is used to detect if changes have been made to the loaded files to determine is hijacked state.
The .copyarea.dat file stores information like:
• When a view was created
• What http server the view was originally connecting to
• The view's Operating System platform
• CCRC remote view tag
The contents of a .copyarea.dat file looks similar to the following:
ClearCase CopyArea|222|ed364ca8f7ee468185bfa528784055ed|a:Windows XP|1c:Thu Mar 10 12:24:08 EST 2005|base|1f:htp://host1/ccase/bin/ccweb.exe|b:user1_host1|20
.COPYAREA.DB
The .copyarea.db file is created in each directory of a CCRC or CCWeb view which contains a list of files that are loaded in the view as well as metadata about the files.
If this file is missing or corrupt, you will notice that all or some of the loaded files will appear to be hijacked.
Also, CCRC and CCWeb keep a record of both the timestamp and a checksum for each element version downloaded. This information is stored in the .copyarea.db file in each directory.
The contents resemble something like:
ClearCase CopyAreaDB|4my_test_vob217:foo.doc|1|1028d7f8806|6000|89a7d530|cc22d419b775452ea0da8bf1b807c616|0
or
ClearCase CopyAreaDB|4
.
2
1
5:testvob|2|0|0|0|cb9bf50026fe43ef96160518044e8c93|0
The CCRC and the ClearCase Web use the following algorithm to detect if a file has been changed:
1. First, the file size is checked. If the file size has changed, then the file has been hijacked.
Next, the file's timestamp is checked. If the timestamp has changed, then the CRC of the file is checked. If the timestamp AND the CRC of the file have changed, then the file has been hijacked. If only the timestamp changed, but the CRC is still the same, then the new timestamp is updated in the copyarea.db.
Clearcase : VOBs database
Posted by
Mahanthesh KN
comments (0)
Introduction to VOBs database
The VOB storage directory has numerous sub-directories in it. The four main areas of VOB storage are source pools, cleartext pools, derived object pools, and the database. Things can go wrong in any of these areas.
The VOB database (the db subdirectory) is one of the more important parts of the system (along with the source pools, which are in the s subdirectory). Taking a closer look at the database, we see that it uses the Raima proprietary format (where Raima is a company that's gone out of business twice since we started using
them). There's one database per VOB; on a VOB server, no matter how many VOBs you have, there will be just one database in each VOB storage directory. The database consists of 8 major files:
* Three data files (.d01 through .d03), which contain the actual data
* Four key files (.k01 through .k04), which contain indexes for random access into the data files
* String file (.str_file), which contains configuration records, among other things
Possible Problems and Their Causes
Three main types of things can go wrong:
01. Corruption in source containers : Source containers get corrupted for a variety of reasons, usually network-related. These reasons include: NFS problems that create zeroes in the middle of the files; network problems such as fragmentation or reassembly errors for large NFS packets; or faulty NICs (network interface cards).
02. VOB accesses not working : VOB accesses can stop working because you ran out of disk space or hit an OS file size limitation (2 GB on some systems) or internal database limitation (particularly in ClearCase 3.0 or schema version 53). If you encounter one of these problems, you're in big trouble, because you won't be allowed to write anything else into the VOB.
03. Data loss or corruption in the VOB database : Hardware-induced failures, Software-induced failures, from either the operating system or ClearCase (in Raima), try to remove individual database files to save space.
Detecting Data Loss or Corruption
Symptoms of having a corrupt VOB database include the following:
* You're unable to access the VOB or VOB objects. (cleartool commands fail, reporting an error like a database ID not found.)
* Either scrubber or vob_scrubber fails.
* You can't lock the VOB (which in general means you can't do any write transactions to the database).
* You can't replicate (or import replica packets). This indicates possible database corruption, but it might also just indicate divergence, depending on the error logs.
* Reformatting the VOB fails. In this case, the database is almost certainly corrupt.
The only two processes that talk to the VOB database are db_server and vobrpc_server. In their ClearCase log files, you'll see messages like these in the event of data loss or corruption:
* Unable to open VOB database - This isn't critical. It usually means you've tried to move or copy the VOB without maintaining the proper permissions on a subset of files in the VOB storage directory tree).
* db_VISTA error nnn- You'll see error numbers like -922, -909, and -6. Note that db_VISTA is essentially synonymous with Raima; anything that's a db_VISTA error is a Raima problem, although not necessarily a corruption. Raima could be having problems with the system, as in not being able to see it, read it, or write to it. This message can also mean that the API being used in ClearCase to interact with Raima is returning an error code.
* Internal error in VOB database, Unexpected error in VOB database, or Something not found in VOB database (basically, "I don't know what you're looking for, but it's not there") - If you see one of these not-so-useful messages, please call Rational Technical Support right away; don't wait a few months or ignore it altogether.
Detecting When a VOB Is Near a Limit
A VOB can stop working if it's near a limit. To detect how full a VOB database is, two utilities are available from Technical Support: countdb analyzes the data (.d01-.d03) files, and string_report analyzes the string file.
The VOB storage directory has numerous sub-directories in it. The four main areas of VOB storage are source pools, cleartext pools, derived object pools, and the database. Things can go wrong in any of these areas.
The VOB database (the db subdirectory) is one of the more important parts of the system (along with the source pools, which are in the s subdirectory). Taking a closer look at the database, we see that it uses the Raima proprietary format (where Raima is a company that's gone out of business twice since we started using
them). There's one database per VOB; on a VOB server, no matter how many VOBs you have, there will be just one database in each VOB storage directory. The database consists of 8 major files:
* Three data files (.d01 through .d03), which contain the actual data
* Four key files (.k01 through .k04), which contain indexes for random access into the data files
* String file (.str_file), which contains configuration records, among other things
Possible Problems and Their Causes
Three main types of things can go wrong:
01. Corruption in source containers : Source containers get corrupted for a variety of reasons, usually network-related. These reasons include: NFS problems that create zeroes in the middle of the files; network problems such as fragmentation or reassembly errors for large NFS packets; or faulty NICs (network interface cards).
02. VOB accesses not working : VOB accesses can stop working because you ran out of disk space or hit an OS file size limitation (2 GB on some systems) or internal database limitation (particularly in ClearCase 3.0 or schema version 53). If you encounter one of these problems, you're in big trouble, because you won't be allowed to write anything else into the VOB.
03. Data loss or corruption in the VOB database : Hardware-induced failures, Software-induced failures, from either the operating system or ClearCase (in Raima), try to remove individual database files to save space.
Detecting Data Loss or Corruption
Symptoms of having a corrupt VOB database include the following:
* You're unable to access the VOB or VOB objects. (cleartool commands fail, reporting an error like a database ID not found.)
* Either scrubber or vob_scrubber fails.
* You can't lock the VOB (which in general means you can't do any write transactions to the database).
* You can't replicate (or import replica packets). This indicates possible database corruption, but it might also just indicate divergence, depending on the error logs.
* Reformatting the VOB fails. In this case, the database is almost certainly corrupt.
The only two processes that talk to the VOB database are db_server and vobrpc_server. In their ClearCase log files, you'll see messages like these in the event of data loss or corruption:
* Unable to open VOB database - This isn't critical. It usually means you've tried to move or copy the VOB without maintaining the proper permissions on a subset of files in the VOB storage directory tree).
* db_VISTA error nnn- You'll see error numbers like -922, -909, and -6. Note that db_VISTA is essentially synonymous with Raima; anything that's a db_VISTA error is a Raima problem, although not necessarily a corruption. Raima could be having problems with the system, as in not being able to see it, read it, or write to it. This message can also mean that the API being used in ClearCase to interact with Raima is returning an error code.
* Internal error in VOB database, Unexpected error in VOB database, or Something not found in VOB database (basically, "I don't know what you're looking for, but it's not there") - If you see one of these not-so-useful messages, please call Rational Technical Support right away; don't wait a few months or ignore it altogether.
Detecting When a VOB Is Near a Limit
A VOB can stop working if it's near a limit. To detect how full a VOB database is, two utilities are available from Technical Support: countdb analyzes the data (.d01-.d03) files, and string_report analyzes the string file.
Clearcase : Restore an element that has been rmnamed
Posted by
Mahanthesh KN
comments (1)
Question : What procedures can be use to restore an IBM® Rational® ClearCase® element whose name has been removed (rmname)?
Cause : A directory used to have a full compliment of file elements, and along the way, some elements had the name removed from the directory using the cleartool rmname command. Note: The Delete operation from within ClearCase Explorer also executes a cleartool rmname, not a cleartool rmelem or cleartool rmver. For example, from within your view, right-click a file or directory element, select Delete, and read the details in the dialogue that appears, then click Cancel.
Answer : There are a few different ways to get the element names back into the directory in question.
Prerequisites: Determine which files are invisible. Here are three methods which can be used to help determine the needed directory version for the next steps:
a. On the branch that your view is set to run the following command to list out all the versions that are not visible (excludes those that are visible).
cleartool find . -all -nvisible -print
b. Within ClearCase Explorer, right click the directory where the element is missing and select Compare with Previous Version to see if the element existed in the previous version of the directory.
The ClearDiff window that is displayed will show the missing element in the left pane of the window. On top of that window you will see a path like the following that identifies version 4 of the directory named "directory" on the main branch: Note: You will need this path information after the version extended syntax (@@) as this is to be used in the link command. From the example, @@\main\4 can be used to find the missing element at the path .@@\main\4\
c. Run the cleartool lshistory command or the History Browser GUI on the directory to find which version of the directory the file was rmnamed which will indicate that it existed in the prior directory version prior to its removal. Note: You will need the previous version of the directory for the next step. For example, say lshistory reports the following:
M:\view\my_test_vob>cleartool lshistory -d -minor -since today
17-May.07:31 user1 create directory version ".@@\main\43"
"Uncataloged file element "cs.txt"."
You will need to use version \main\42 for the next steps.
Restoring the elements
1. Checkout the directory where the element is missing.
2. Use one of the following procedures to restore the element name back to the LATEST version of the directory:
• Create a link using the cleartool ln operation for each element. For example, the missing element is called test.txt
cleartool> ls
foo.c@@\main\13 Rule: \main\LATEST
cleartool> ln .@@\main\4\test.txt .\test.txt
Link created: ".\test.txt".
cleartool> ls
foo.c@@\main\13 Rule: \main\LATEST
test.txt@@\main\7 Rule: \main\LATEST
•
• Merge the directory graphically from the version tree browser:
1. Start the version tree browser for the directory by right-clicking on the file directory, then select Version Tree.
2. After the version tree browser appears, right-click on a version of the directory known to contain the missing file and select Merge to... and select the current version of the directory in use.
3. When the dialog box appears, select Yes, and also select the option Merge the element graphically. Once the merge GUI appears, manually step through the differences between the current version and the selected prior version with the files.
Note: If you need assistance, you can use the Help available from within the Merge Manager tool.
4. Undo the difference resolution for the removed element names and then select the correct contributor you wish to use.
5. Save the results, and close the graphical merge window.
You may need to Refresh your view for the element names to reappear in the directory version that they were just restored to.
6. If the results are correct, then right-click the directory and click Checkin.
• Merge the directory using cleartool merge -delete to "undo" the rmname operation (this option is somewhat more complicated).
Caution: If more than one change was made to the directory in this version, those changes could be reverted as well. Use the cleartool lshistory command to determine what other changes were made to that directory version.
1. Determine the version where the element was rmnamed.
2. Use cleartool merge -delete to remove the changes applied in that version of the directory.
For example:
cleartool merge-to . -delete -version \main\17
3. If the only change made in this version was the removal of the desired element, the change should automatically be made (see about caution).
Cause : A directory used to have a full compliment of file elements, and along the way, some elements had the name removed from the directory using the cleartool rmname command. Note: The Delete operation from within ClearCase Explorer also executes a cleartool rmname, not a cleartool rmelem or cleartool rmver. For example, from within your view, right-click a file or directory element, select Delete, and read the details in the dialogue that appears, then click Cancel.
Answer : There are a few different ways to get the element names back into the directory in question.
Prerequisites: Determine which files are invisible. Here are three methods which can be used to help determine the needed directory version for the next steps:
a. On the branch that your view is set to run the following command to list out all the versions that are not visible (excludes those that are visible).
cleartool find . -all -nvisible -print
b. Within ClearCase Explorer, right click the directory where the element is missing and select Compare with Previous Version to see if the element existed in the previous version of the directory.
The ClearDiff window that is displayed will show the missing element in the left pane of the window. On top of that window you will see a path like the following that identifies version 4 of the directory named "directory" on the main branch: Note: You will need this path information after the version extended syntax (@@) as this is to be used in the link command. From the example, @@\main\4 can be used to find the missing element at the path .@@\main\4\
c. Run the cleartool lshistory command or the History Browser GUI on the directory to find which version of the directory the file was rmnamed which will indicate that it existed in the prior directory version prior to its removal. Note: You will need the previous version of the directory for the next step. For example, say lshistory reports the following:
M:\view\my_test_vob>cleartool lshistory -d -minor -since today
17-May.07:31 user1 create directory version ".@@\main\43"
"Uncataloged file element "cs.txt"."
You will need to use version \main\42 for the next steps.
Restoring the elements
1. Checkout the directory where the element is missing.
2. Use one of the following procedures to restore the element name back to the LATEST version of the directory:
• Create a link using the cleartool ln operation for each element. For example, the missing element is called test.txt
cleartool> ls
foo.c@@\main\13 Rule: \main\LATEST
cleartool> ln .@@\main\4\test.txt .\test.txt
Link created: ".\test.txt".
cleartool> ls
foo.c@@\main\13 Rule: \main\LATEST
test.txt@@\main\7 Rule: \main\LATEST
•
• Merge the directory graphically from the version tree browser:
1. Start the version tree browser for the directory by right-clicking on the file directory, then select Version Tree.
2. After the version tree browser appears, right-click on a version of the directory known to contain the missing file and select Merge to... and select the current version of the directory in use.
3. When the dialog box appears, select Yes, and also select the option Merge the element graphically. Once the merge GUI appears, manually step through the differences between the current version and the selected prior version with the files.
Note: If you need assistance, you can use the Help available from within the Merge Manager tool.
4. Undo the difference resolution for the removed element names and then select the correct contributor you wish to use.
5. Save the results, and close the graphical merge window.
You may need to Refresh your view for the element names to reappear in the directory version that they were just restored to.
6. If the results are correct, then right-click the directory and click Checkin.
• Merge the directory using cleartool merge -delete to "undo" the rmname operation (this option is somewhat more complicated).
Caution: If more than one change was made to the directory in this version, those changes could be reverted as well. Use the cleartool lshistory command to determine what other changes were made to that directory version.
1. Determine the version where the element was rmnamed.
2. Use cleartool merge -delete to remove the changes applied in that version of the directory.
For example:
cleartool merge-to . -delete -version \main\17
3. If the only change made in this version was the removal of the desired element, the change should automatically be made (see about caution).
Clearcase : Why Elements Are Moved to the VOB lost+found Directory
Posted by
Mahanthesh KN
comments (1)
An object will be placed in a VOB's lost+found directory when the parent directory namespace has been removed (in which case there is no longer a context in which to show the object) or altered such that it's contents have no reference in a previous directory version. This can happen under the following circumstances:
1. The object's parent directory element is removed with rmelem and there are no other hardlinks to the object elsewhere in the VOB.
Example:
%>cleartool rmelem dir1
CAUTION! This will destroy the element, all its branches and versions, including all data, meta-data and history, and will remove the element from all directory versions that now contain it. Once you destroy the element, there will be no way to restore it to its current state. If you want to preserve the element, but remove references to it from future directory versions, use the "rmname" command.
Element "dir1" has 1 branches, 2 versions, and is entered in 1 directory versions. Destroy element? [no] y
cleartool: Warning: Object "foo.c" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as "foo.c.986de380d90b479db49316560deba2f2".
Removed element "dir1".
2. The parent directory is checked out, files and/or directories are added, and then the parent directory is unchecked out.
Example:
%>cleartool co -nc dir1
Checked out "dir1" from version "/main/7".
%>cleartool mkelem -ci -nc foo.c
Created element "foo.c" (type "text_file").
Checked in "foo.c" version "/main/1".
%>cleartool unco dir1
cleartool: Warning: Object "foo.c" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as
"foo.c.c7592f61ab0b11db83b5000180f96245".
Checkout cancelled for "dir1".
3. The parent directory is checked out, files and/or directories are added, and then the file or directory has its name removed (rmname) before the parent directory is checked in.
Example:
%>cleartool co -nc dir1
Checked out "dir1" from version "/main/7".
%>cleartool mkelem -ci -nc foo.c
Created element "foo.c" (type "text_file").
Checked in "foo.c" version "/main/1".
%>cleartool rmname foo.c
cleartool: Warning: Object "foo.c" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as
"foo.c.c7592f61ab0b11db83b5000180f96245".
Removed "foo.c".
When an object is moved to the lost+found root directory its OID (object ID) is appended to the original filename. For example:
Before : foo.c
After : foo.c.282d5d339cba4043905da6ca201e1f3d
If a directory element is moved to lost+found, all of the subdirectories and elements it contains are moved along with it (the directory structure is kept intact). Since these contents are not located in the lost+found root, however, they are not renamed in the manner described above.
1. The object's parent directory element is removed with rmelem and there are no other hardlinks to the object elsewhere in the VOB.
Example:
%>cleartool rmelem dir1
CAUTION! This will destroy the element, all its branches and versions, including all data, meta-data and history, and will remove the element from all directory versions that now contain it. Once you destroy the element, there will be no way to restore it to its current state. If you want to preserve the element, but remove references to it from future directory versions, use the "rmname" command.
Element "dir1" has 1 branches, 2 versions, and is entered in 1 directory versions. Destroy element? [no] y
cleartool: Warning: Object "foo.c" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as "foo.c.986de380d90b479db49316560deba2f2".
Removed element "dir1".
2. The parent directory is checked out, files and/or directories are added, and then the parent directory is unchecked out.
Example:
%>cleartool co -nc dir1
Checked out "dir1" from version "/main/7".
%>cleartool mkelem -ci -nc foo.c
Created element "foo.c" (type "text_file").
Checked in "foo.c" version "/main/1".
%>cleartool unco dir1
cleartool: Warning: Object "foo.c" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as
"foo.c.c7592f61ab0b11db83b5000180f96245".
Checkout cancelled for "dir1".
3. The parent directory is checked out, files and/or directories are added, and then the file or directory has its name removed (rmname) before the parent directory is checked in.
Example:
%>cleartool co -nc dir1
Checked out "dir1" from version "/main/7".
%>cleartool mkelem -ci -nc foo.c
Created element "foo.c" (type "text_file").
Checked in "foo.c" version "/main/1".
%>cleartool rmname foo.c
cleartool: Warning: Object "foo.c" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as
"foo.c.c7592f61ab0b11db83b5000180f96245".
Removed "foo.c".
When an object is moved to the lost+found root directory its OID (object ID) is appended to the original filename. For example:
Before : foo.c
After : foo.c.282d5d339cba4043905da6ca201e1f3d
If a directory element is moved to lost+found, all of the subdirectories and elements it contains are moved along with it (the directory structure is kept intact). Since these contents are not located in the lost+found root, however, they are not renamed in the manner described above.
ClearCase : Certification Questions
Posted by
Mahanthesh KN
comments (0)
1. Which of the following actions can you complete using the clearlicense command? (Select all that apply)
A. Enable license auditing
B. Release a license
C. Report on current license use
D. Add new license Codes
E. Grant licenses to priority users
Answer: A, B, C
2. The cleartool casts command will display the configuration record of a build object.
A. True
B. False
Answer: B
B. Release a license
C. Report on current license use
D. Add new license Codes
E. Grant licenses to priority users
Answer: A, B, C
2. The cleartool casts command will display the configuration record of a build object.
A. True
B. False
Answer: B
3. Which command allow a user to obtain command syntax help from the command prompt? (Select all that apply)
A. cleartool subcommand -help
B. cleartool -help subcommand
C. cleartool help subcommand
D. cleartool subcommand help
Answer: A, C
A. cleartool subcommand -help
B. cleartool -help subcommand
C. cleartool help subcommand
D. cleartool subcommand help
Answer: A, C
4. What is the length of the default timeout period on a ClearCase license?
A. 15 minutes
B. 30 minutes
C. 60 minutes
D. 120 minutes
Answer: C
A. 15 minutes
B. 30 minutes
C. 60 minutes
D. 120 minutes
Answer: C
5. ClearCase for UNIX supports remote storage pools for derived object and cleartext pools.
A. True
B. False
Answer: A
A. True
B. False
Answer: A
6. What cleartool command do you use to list the derived objects created by clearmake?
A. diffcr
B. catcs
C. catcr -flat
D. lsdo
E. ls - la
Answer: D
A. diffcr
B. catcs
C. catcr -flat
D. lsdo
E. ls - la
Answer: D
7. Can a snapshot view's view.dat file be moved to a network server host without ill effects?
A. Yes
B. No
Answer: B
A. Yes
B. No
Answer: B
8. A user can change from write access to read-only access on a checked-out version by issuing the
cleartool protect ugo.w command.
A. True
B. False
Answer: B
cleartool protect ugo.w command.
A. True
B. False
Answer: B
9. How does a derived object inherit its pool assignment?
A. From the file element that created the first-level target
B. From the directory where the executable is versioned
C. From the directory where the target was built
D. From the derived object assignment tables
Answer: C
A. From the file element that created the first-level target
B. From the directory where the executable is versioned
C. From the directory where the target was built
D. From the derived object assignment tables
Answer: C
10. Which operation (s) requires the registry password? (Select all that apply)
A. Change the registry password
B. Change a private VOB to a public VOB
C. Remove a public VOB
D. Create a public VOB
Answer: B, D
A. Change the registry password
B. Change a private VOB to a public VOB
C. Remove a public VOB
D. Create a public VOB
Answer: B, D
11. What is the effect of using cleartool chpool on a file element? (Select all that apply)
A. For cleatext pools, future versions will be put in the new pool.
B. For source pools, future versions will be put in the new pool.
C. For cleartext pools, all versions are moved to the new pool.
D. For source pools, all versions are moved to the new pool.
Answer: A, D
A. For cleatext pools, future versions will be put in the new pool.
B. For source pools, future versions will be put in the new pool.
C. For cleartext pools, all versions are moved to the new pool.
D. For source pools, all versions are moved to the new pool.
Answer: A, D
12. You want to get detailed information about a build. What do you examine?
A. Configuration records
B. Derived objects
C. Makefile
D. View's lo files
E. Configuration specification
Answer: A
A. Configuration records
B. Derived objects
C. Makefile
D. View's lo files
E. Configuration specification
Answer: A
13. A user can specify a VOB to mount with either the VOB-tag or the VOB storage pathname.
A. True
B. False
Answer: B
A. True
B. False
Answer: B
14. Which of the following element types does ClearCase store as interleaved deltas? (Select all that
apply)
A. text_file
B. html
C. ms_word
D. xml
Answer: A, B, D
apply)
A. text_file
B. html
C. ms_word
D. xml
Answer: A, B, D
15. The commands clearexport_ccase and clearimport copy elements from one VOB to another.
A. True
B. False
Answer: A
A. True
B. False
Answer: A
16. Which host is executing the view_server process for a snapshot view?
A. The host where the view storage directory resides
B. The host where view_private files are loaded
C. The same host as the vob_server process
D. The host that first activates the view
Answer: A
A. The host where the view storage directory resides
B. The host where view_private files are loaded
C. The same host as the vob_server process
D. The host that first activates the view
Answer: A
17. Any member of any group can change the config spec of a view.
A. True
B. False
Answer: B
A. True
B. False
Answer: B
18. Only the owner of a ClearCase object can transfer ownership of that object.
A. True
B. False
Answer: B
A. True
B. False
Answer: B
19. The semi-live backup strategy minimizes VOB downtime by locking the VOB only long enough to copy the database subdirectory of the VOB's physical storage area.
A. True
B. False
Answer: A
A. True
B. False
Answer: A
20. Which of the following actions can you complete using the clearicense command? (Select all that
apply)
A. Enable license auditing
B. Report on current license use
C. Release a license
D. Add new license codes
E. Establish priority user licenses.
Answer: A, B, C
21. To access views and VOB's from a region they must have a tag in that region.
A. True
B. False
Answer: A
22. What is the purpose of the cleartool protectvob command? (Select all that apply)
A. Change the ownership of VOB
B. Change the primary group of a VOB
C. List the owner and groups for a VOB
D. Add groups to a newly created VOB
E. Remove the primary group Of a VOB
Answer: B
A. Change the ownership of VOB
B. Change the primary group of a VOB
C. List the owner and groups for a VOB
D. Add groups to a newly created VOB
E. Remove the primary group Of a VOB
Answer: B
23. The storage directories of the dynamic view and snapshot view contain the same subdirectories.
A. True
B. False
Answer: A
A. True
B. False
Answer: A
24. Which of the following objects are available in the ClearCase Explorer display? (Select all that apply)
A. Hyperlink
B. View-private file
C. Hard link
D. DIRECTORY ELEMENT
E. Symbolic link
Answer: A, B, C
A. Hyperlink
B. View-private file
C. Hard link
D. DIRECTORY ELEMENT
E. Symbolic link
Answer: A, B, C
25. The default behavior of the clearesport_rcs and clearexport_pvcs commands is to translate
symbols into labels or branches as appropriate.
A. True
B. False
Answer: A
symbols into labels or branches as appropriate.
A. True
B. False
Answer: A
26. Entering a ClearCase command causes a trigger to fire. The trigger's associated script
references a comment linked with that command. Which environment variable does the script use
to identify the comment entered with the ClearCase command?
A. CLEARCASE_CMNT_PN
B. CLEARCASE_CQ
C. CLEARCASE_CFILE
D. CLEARCASE_DESCRIP
E. CLEARCASE_COMMENT
Answer: E
27. The VOB semi-live backup strategy is only available for version 3.2.1 and higher VOB's
A. True
B. False
Answer: B
A. True
B. False
Answer: B
28. On the host where the view storage directory resides, an asterisk ( * ) appears to the left of a view- tag in Isview output. What does the asterisk mean? (Select all that apply)
A. View storage directory resides on the local host.
B. View server process is running
C. View is currently in use
D. View is visible on the MVFS drive
Answer: B, D
A. View storage directory resides on the local host.
B. View server process is running
C. View is currently in use
D. View is visible on the MVFS drive
Answer: B, D
29. host's MVFS (M:) drive has a subdirectory for every active dynamic view on the host.
Under which of the following conditions does a dynamic view become active? (Slect all that apply)
A. View server process is started on that host
B. Cleartool startview comman is executed on the host
C. View is set on that host with cleartool setview
D. ALDB server process is started on that host
Answer: A, B
30. You must run the cleartool protectvob command when the VOB is unmounted on all hosts.
A. True
B. False
Answer: B
A. True
B. False
Answer: B
31. You can restart the cleartool relocate command for all phases except if it has halted during the
final phase (removal of source elements).
A. True
B. False
Answer: A
32. Which of the following commands must you issue from the command prompt to shut down
ClearCase? (Select all that apply)
A. net stop vob_server
B. net stop lockmgr
C. net stop clearcase_albd
D. net stop mvfs
E. net stop albd
Answer: A, B, C
final phase (removal of source elements).
A. True
B. False
Answer: A
32. Which of the following commands must you issue from the command prompt to shut down
ClearCase? (Select all that apply)
A. net stop vob_server
B. net stop lockmgr
C. net stop clearcase_albd
D. net stop mvfs
E. net stop albd
Answer: A, B, C
33. It is essential to back up a view because objects in a view's storage directory cannot be accessed
by other view?
A. True
B. False
Answer: A
34. What happens to non-versioned derived objects after cleartool relocate executes?
A. They are relocated to the target VOB.
B. They are not relocated.
C. They are deleted.
D. They are invalid in the originating VOB.
Answer: C
35. The cleartool catcs command will display the configuration record of a built object.
A. True
B. False
Answer: B
by other view?
A. True
B. False
Answer: A
34. What happens to non-versioned derived objects after cleartool relocate executes?
A. They are relocated to the target VOB.
B. They are not relocated.
C. They are deleted.
D. They are invalid in the originating VOB.
Answer: C
35. The cleartool catcs command will display the configuration record of a built object.
A. True
B. False
Answer: B
36. Unprivilieged ClearCase users have read-only access to the ClearCase Properties applet.
A. True
B. False
Answer: B
A. True
B. False
Answer: B
37. It is necessary to reboot the computer after uninstalling ClearCase.
A. True
B. False
Answer: A
A. True
B. False
Answer: A
38. The ClearCase Server Storage Configuration Wizard sets up view and VOB share directories,
which are suggested to clients when they create the respective dta structures via the Create VOB
or Create View Wizard.
A. True
B. False
Answer: A
which are suggested to clients when they create the respective dta structures via the Create VOB
or Create View Wizard.
A. True
B. False
Answer: A
39. Which host is executing the view_server process for a dynamic view?
A. The host that first activates the view
B. The host wher view_private files are loaded
C. The same host as the vob_server process.
D. The host where the view storage directory physically resides.
Answer: D
A. The host that first activates the view
B. The host wher view_private files are loaded
C. The same host as the vob_server process.
D. The host where the view storage directory physically resides.
Answer: D
40. Which of the following options of the cleartool subcommand getlog returns a listing of all log files on their current host? (Select all that apply)
A. getlog - long
B. getlog - inquire
C. getlog - isall
D. getlog - graphical
Answer: B, D
A. getlog - long
B. getlog - inquire
C. getlog - isall
D. getlog - graphical
Answer: B, D
41. The command recoverview calls cleartool reformatview.
A. True
B. False
Answer: A
A. True
B. False
Answer: A
42. The ClearCase network release area must be on a Clear Case installed host.
A. True
B. False
Answer: B
A. True
B. False
Answer: B
43. A user may access VOB data either by making the VOB -tag or the VOB storage directory the
current directory.
A. True
B. False
Answer: B
current directory.
A. True
B. False
Answer: B
Clearcase : Environment variables that can be used in triggers
Posted by
Mahanthesh KN
comments (0)
CLEARCASE_CMDLINE -- This contains the command and arguments run from cleartool.
CLEARCASE_COMMENT -- Comment string for the command.
CLEARCASE_COMPONENT -- The UCM component.
CLEARCASE_ELTYPE -- Element type of the element.
CLEARCASE_FOLDER -- The folder that contains the project.
CLEARCASE_FREPLICA -- The old master replica, or from-replica.
CLEARCASE_FTEXT -- Text associated with hyperlink from-object.
CLEARCASE_FTYPE -- The type of the hyperlink being applied or removed is from.
CLEARCASE_FVOB_PN -- Pathname of VOB containing hyperlink from-object.
CLEARCASE_FXPN -- VOB-extended pathname of hyperlink from-object.
CLEARCASE_HLTYPE -- Hyperlink type
CLEARCASE_ID_STR -- Version-ID of a version, or branch pathname of branch.
CLEARCASE_LBTYPE -- Label type.
CLEARCASE_MTYPE -- Kind (element type, branch type, directory version etc?)
CLEARCASE_NEW_TYPE -- New name of the renamed type object.
CLEARCASE_OP_KIND -- Operation that caused the trigger to fire.
CLEARCASE_OUT_PN -- Pathname in checkout -out.
CLEARCASE_PN -- Name of element specified in the command.
CLEARCASE_POP_KIND -- Parent operation kind.
CLEARCASE_PPID -- Parent Process ID.
CLEARCASE_PROJECT -- The UCM project.
CLEARCASE_REPLACE -- Set to 1 if the user specified -replace on the command line.
CLEARCASE_RESERVED -- Set to 1 if the -reserved checkedout is specified.
CLEARCASE_SLNKTXT -- Text of the new VOB symbolic link.
CLEARCASE_SNAPSHOT_PN -- The path to the root of the snapshot view directory.
CLEARCASE_STREAM -- The UCM stream.
CLEARCASE_TO_ACTIVITY -- The activity that will contain the versions of elements.
CLEARCASE_TO_FOLDER -- The folder that will contain the project or folder.
CLEARCASE_TREPLICA -- The new master replica, or to-replica.
CLEARCASE_TRTYPE -- Trigger type.
CLEARCASE_TRTYPE_KIND -- Kind of trigger type.
CLEARCASE_TTEXT -- Text associated with hyperlink to-object.
CLEARCASE_TYPE -- Object selector of the type which the hyperlink being applied or removed CLEARCASE_TVOB_PN -- Pathname of VOB containing hyperlink to-object.
CLEARCASE_TXPN -- VOB-extended pathname of hyperlink to-object.
CLEARCASE_USER -- The user who issued the command.
CLEARCASE_VIEW_KIND -- The kind of view.
CLEARCASE_VIEW_TAG -- View-tag of the view.
CLEARCASE_VOB_PN -- VOB-tag of the VOB or UCM project VOB.
CLEARCASE_IS_FROM -- Set to 1 if CLEARCASE_PN contains name of hyperlink from-object; set to 0 if CLEARCASE_PN contains name of hyperlink to-object.
CLEARCASE_DLVR_ACTS -- A space-separated list of all UCM activities merged during the deliver operation.
CLEARCASE_MODTYPE -- Object selector of the type for which the attribute or hyperlink is being applied or removed
CLEARCASE_XN_SFX -- Extended naming symbol (such as @@) for host. CLEARCASE_XPN -- Same as CLEARCASE_ID_STR, but prepended with CLEARCASE_PN and CLEARCASE_XN_SFX values.
CLEARCASE_COMMENT -- Comment string for the command.
CLEARCASE_COMPONENT -- The UCM component.
CLEARCASE_ELTYPE -- Element type of the element.
CLEARCASE_FOLDER -- The folder that contains the project.
CLEARCASE_FREPLICA -- The old master replica, or from-replica.
CLEARCASE_FTEXT -- Text associated with hyperlink from-object.
CLEARCASE_FTYPE -- The type of the hyperlink being applied or removed is from.
CLEARCASE_FVOB_PN -- Pathname of VOB containing hyperlink from-object.
CLEARCASE_FXPN -- VOB-extended pathname of hyperlink from-object.
CLEARCASE_HLTYPE -- Hyperlink type
CLEARCASE_ID_STR -- Version-ID of a version, or branch pathname of branch.
CLEARCASE_LBTYPE -- Label type.
CLEARCASE_MTYPE -- Kind (element type, branch type, directory version etc?)
CLEARCASE_NEW_TYPE -- New name of the renamed type object.
CLEARCASE_OP_KIND -- Operation that caused the trigger to fire.
CLEARCASE_OUT_PN -- Pathname in checkout -out.
CLEARCASE_PN -- Name of element specified in the command.
CLEARCASE_POP_KIND -- Parent operation kind.
CLEARCASE_PPID -- Parent Process ID.
CLEARCASE_PROJECT -- The UCM project.
CLEARCASE_REPLACE -- Set to 1 if the user specified -replace on the command line.
CLEARCASE_RESERVED -- Set to 1 if the -reserved checkedout is specified.
CLEARCASE_SLNKTXT -- Text of the new VOB symbolic link.
CLEARCASE_SNAPSHOT_PN -- The path to the root of the snapshot view directory.
CLEARCASE_STREAM -- The UCM stream.
CLEARCASE_TO_ACTIVITY -- The activity that will contain the versions of elements.
CLEARCASE_TO_FOLDER -- The folder that will contain the project or folder.
CLEARCASE_TREPLICA -- The new master replica, or to-replica.
CLEARCASE_TRTYPE -- Trigger type.
CLEARCASE_TRTYPE_KIND -- Kind of trigger type.
CLEARCASE_TTEXT -- Text associated with hyperlink to-object.
CLEARCASE_TYPE -- Object selector of the type which the hyperlink being applied or removed CLEARCASE_TVOB_PN -- Pathname of VOB containing hyperlink to-object.
CLEARCASE_TXPN -- VOB-extended pathname of hyperlink to-object.
CLEARCASE_USER -- The user who issued the command.
CLEARCASE_VIEW_KIND -- The kind of view.
CLEARCASE_VIEW_TAG -- View-tag of the view.
CLEARCASE_VOB_PN -- VOB-tag of the VOB or UCM project VOB.
CLEARCASE_IS_FROM -- Set to 1 if CLEARCASE_PN contains name of hyperlink from-object; set to 0 if CLEARCASE_PN contains name of hyperlink to-object.
CLEARCASE_DLVR_ACTS -- A space-separated list of all UCM activities merged during the deliver operation.
CLEARCASE_MODTYPE -- Object selector of the type for which the attribute or hyperlink is being applied or removed
CLEARCASE_XN_SFX -- Extended naming symbol (such as @@) for host. CLEARCASE_XPN -- Same as CLEARCASE_ID_STR, but prepended with CLEARCASE_PN and CLEARCASE_XN_SFX values.
Clearcase : About ClearCase server processes
Posted by
Mahanthesh KN
comments (0)
albd_server process
When a client program needs access to a service (a VOB or view server, for example) on a ClearCase server host, it uses a remote procedure call (RPC) to send a request to the albd_server process on that host. The albd_server starts the requested service if it is not already started, and provides the service’s port number to the client. Thereafter, the client communicates directly with the service.
The albd_server handles a variety of tasks on hosts configured to support local VOBs and views:
•Starting and stopping other Rational ClearCase services as needed.
•Setting up network communications between Rational ClearCase clients and servers.
•Managing execution of tasks run by the Rational ClearCase scheduler.
•Responding to requests for registry information on a Rational ClearCase registry server host.
•Responding to requests for licenses on a Rational ClearCase license server host. (Rational ClearCase LT does not use the albd_server in this way.)
admin_server process
The ClearCase administration server (admin_server) is invoked as needed by the host’s albd_server process. This short-lived server performs miscellaneous administrative support functions.
The admin_server handles the following tasks:
* Retrieving the server log files displayed by the getlog command and the Rational ClearCase Administration Console.
* Retrieving and changing the Rational ClearCase properties on the local host when requested by the Rational ClearCase Administration Console.
* Moving registry files and reconfiguring clients if the host is a backup registry server.
credmap_server process
The credentials mapping server,credmap_server, runs on any Rational ClearCase host that is configured to support local VOBs and views. This server handles credentials mapping in environments where users access a common set of VOBs and views from computers running different supported operating systems.
view_server process
A view_server is a long-lived process that manages activity in a particular view. A view_server is started by the host’s albd_server process whenever a client requests access to a view. A view_server remains active until it is terminated by a cleartool endview –server command, a system shutdown, or an operating system command that terminates the view_server process.
When it begins execution, a view_server reads configuration information from the .view file in the view-storage directory. Values in this file are established by mkview, chview, and similar commands. Do not modify this file with a text editor.
vob_server process
For each VOB, a long-lived vob_server process runs on the VOB host. The vob_server manipulates data in the VOB storage pools in response to requests from client processes.
The vob_server is the only process that creates or deletes VOB data containers; only the VOB owner or a privileged user can modify VOB data containers and storage pools. For more information, see The VOB storage directory.
A vob_server process is started as needed by thealbd_server process. It remains active until any of the following events occur:
* The VOB is removed with the rmvob command.
* Rational® ClearCase® is stopped on the VOB server host.
* The VOB server host is shut down and restarted.
When it begins execution, the vob_server reads configuration information from the file vob_server.conf in the VOB storage directory. Values in this file are established by the vob_snapshot_setup utility and other commands. Do not modify this file.
db_server process
The db_server processes manage VOB database transactions on a host in response to requests from client programs. Because client programs cannot access VOB databases directly, they must send database transaction requests to a db_server process when they must create, read, or modify VOB data or metadata.
Each db_server process services a single client at a time, but can operate on any number of VOBs. A client establishes a connection to a db_server with the help of the albd_server on the VOB host. If necessary, the albd_server starts a new db_server process to handle a request. The connection is broken when the client exits or becomes idle (stops requesting database transactions for an extended period). At that point, the db_server becomes available for use by another client. After a period of idleness, an unconnected db_server is terminated by its host’s albd_server process.
vobrpc_server process
Each VOB server host runs one or more vobrpc_server processes for each of its VOBs. Each vobrpc_server process handles requests from view_server processes throughout the network. These requests can generate both metadata (VOB database) and file-system data (storage pool) activity. The vobrpc_server process accesses the VOB database in the same way as a db_server; it forwards storage pool access requests to the vob_server.
The vobrpc_server processes are started by thealbd_server process, which also routes new requests to the least-busy servers and terminates unneeded vobrpc_server processes when the system is lightly loaded.
lockmgr process
On Windows hosts and some Linux hosts that are VOB servers, a lock manager arbitrates transaction requests to all VOB databases on that host. When a process requests VOB data, the lockmgr process or the VOB's db_server grants or prohibits access to that data. If the data is available, the transaction proceeds immediately: the data is read or written, and output is returned to the calling program. If the data is unavailable (locked because another caller has been granted write access to the data), the caller waits until the lockmgr or db_server grants access to the data.
rwp process
The IBM Rational Web Platform rwp provides application support for the Rational® ClearCase® Remote Client and Rational ClearCase Web Client.
RWP servers are usually configured during installation and need no further administrative attention unless special configurations (for example, a configuration to support access by proxy) are required. A Rational ClearCase community may have one or more rwp servers.
When a client program needs access to a service (a VOB or view server, for example) on a ClearCase server host, it uses a remote procedure call (RPC) to send a request to the albd_server process on that host. The albd_server starts the requested service if it is not already started, and provides the service’s port number to the client. Thereafter, the client communicates directly with the service.
The albd_server handles a variety of tasks on hosts configured to support local VOBs and views:
•Starting and stopping other Rational ClearCase services as needed.
•Setting up network communications between Rational ClearCase clients and servers.
•Managing execution of tasks run by the Rational ClearCase scheduler.
•Responding to requests for registry information on a Rational ClearCase registry server host.
•Responding to requests for licenses on a Rational ClearCase license server host. (Rational ClearCase LT does not use the albd_server in this way.)
admin_server process
The ClearCase administration server (admin_server) is invoked as needed by the host’s albd_server process. This short-lived server performs miscellaneous administrative support functions.
The admin_server handles the following tasks:
* Retrieving the server log files displayed by the getlog command and the Rational ClearCase Administration Console.
* Retrieving and changing the Rational ClearCase properties on the local host when requested by the Rational ClearCase Administration Console.
* Moving registry files and reconfiguring clients if the host is a backup registry server.
credmap_server process
The credentials mapping server,credmap_server, runs on any Rational ClearCase host that is configured to support local VOBs and views. This server handles credentials mapping in environments where users access a common set of VOBs and views from computers running different supported operating systems.
view_server process
A view_server is a long-lived process that manages activity in a particular view. A view_server is started by the host’s albd_server process whenever a client requests access to a view. A view_server remains active until it is terminated by a cleartool endview –server command, a system shutdown, or an operating system command that terminates the view_server process.
When it begins execution, a view_server reads configuration information from the .view file in the view-storage directory. Values in this file are established by mkview, chview, and similar commands. Do not modify this file with a text editor.
vob_server process
For each VOB, a long-lived vob_server process runs on the VOB host. The vob_server manipulates data in the VOB storage pools in response to requests from client processes.
The vob_server is the only process that creates or deletes VOB data containers; only the VOB owner or a privileged user can modify VOB data containers and storage pools. For more information, see The VOB storage directory.
A vob_server process is started as needed by thealbd_server process. It remains active until any of the following events occur:
* The VOB is removed with the rmvob command.
* Rational® ClearCase® is stopped on the VOB server host.
* The VOB server host is shut down and restarted.
When it begins execution, the vob_server reads configuration information from the file vob_server.conf in the VOB storage directory. Values in this file are established by the vob_snapshot_setup utility and other commands. Do not modify this file.
db_server process
The db_server processes manage VOB database transactions on a host in response to requests from client programs. Because client programs cannot access VOB databases directly, they must send database transaction requests to a db_server process when they must create, read, or modify VOB data or metadata.
Each db_server process services a single client at a time, but can operate on any number of VOBs. A client establishes a connection to a db_server with the help of the albd_server on the VOB host. If necessary, the albd_server starts a new db_server process to handle a request. The connection is broken when the client exits or becomes idle (stops requesting database transactions for an extended period). At that point, the db_server becomes available for use by another client. After a period of idleness, an unconnected db_server is terminated by its host’s albd_server process.
vobrpc_server process
Each VOB server host runs one or more vobrpc_server processes for each of its VOBs. Each vobrpc_server process handles requests from view_server processes throughout the network. These requests can generate both metadata (VOB database) and file-system data (storage pool) activity. The vobrpc_server process accesses the VOB database in the same way as a db_server; it forwards storage pool access requests to the vob_server.
The vobrpc_server processes are started by thealbd_server process, which also routes new requests to the least-busy servers and terminates unneeded vobrpc_server processes when the system is lightly loaded.
lockmgr process
On Windows hosts and some Linux hosts that are VOB servers, a lock manager arbitrates transaction requests to all VOB databases on that host. When a process requests VOB data, the lockmgr process or the VOB's db_server grants or prohibits access to that data. If the data is available, the transaction proceeds immediately: the data is read or written, and output is returned to the calling program. If the data is unavailable (locked because another caller has been granted write access to the data), the caller waits until the lockmgr or db_server grants access to the data.
rwp process
The IBM Rational Web Platform rwp provides application support for the Rational® ClearCase® Remote Client and Rational ClearCase Web Client.
RWP servers are usually configured during installation and need no further administrative attention unless special configurations (for example, a configuration to support access by proxy) are required. A Rational ClearCase community may have one or more rwp servers.
Clearcase : Questions_01
Posted by
Mahanthesh KN
comments (0)
how to restore elements from lost+found directory
Checkout the destination directory where you want to move the elements from lost+found directory.
Use the command cleartool mv
what is the default vob size when it is created at first time?
0.8 MB
what is the difference between operating system shell and Clearcase shell?
As such there s no difference in the shell. As Clearcase is a tool that works on the OS shell, you need to set up Path for your Clearcase tool to recognize the cleartool command.
What is eclipse and how to resolve the problem?
A VOB object that is not visible because another object with the same name is currently selected by the view. Delete view private version.
What is evil twin and how to resolve the problem?
"Evil Twins" is, two elements of the same name, are created in two different versions of the same directory element.
Advantages of Rational ClearCase over other SCM tool i.e Microsoft Visual Source Safe?
The multisite is the best part of clearcase than any other tool
The beauty of clearcase lies in its conecpts of config spec and views
In CLearcase performance is better supports more data size
What is the name of the Network protocols used by ClearCase?
The protocols used for network communications are TCP (Transmission Control Protocol) and UDP (User Datagram Protocol), which are layered over IP (Internet Protocol). Most processes use TCP, but for optimization some use UDP. The protocol that a ClearCase server process uses is hard coded and cannot be manually configured, changed or disabled
What is the Config Spec?
A config spec is the mechanism that a ClearCase View determines what versions of an element that the user accesses. A config spec is only editable, by default, by the account that created the View. A config spec has a single rule on each line, and the lines are interpreted by ClearCase from the top to the bottom as the order of importance.
What Credentials Manager service do?
ClearCase does not have a built-in authentication mechanism, and makes use of the security and access controls provided by the Windows operating system. The credentials manager Service, cccredmgr, registers the ClearCase group security identifier (SID) at system startup with MVFS.
What are clearcase metadata ?
Metadata is set of constructs and annotations that attach to clearcase objects. It manages you to organize, manipulate and manage those objects. Enables you to find , list. sort and retrieve information
Checkout the destination directory where you want to move the elements from lost+found directory.
Use the command cleartool mv
what is the default vob size when it is created at first time?
0.8 MB
what is the difference between operating system shell and Clearcase shell?
As such there s no difference in the shell. As Clearcase is a tool that works on the OS shell, you need to set up Path for your Clearcase tool to recognize the cleartool command.
What is eclipse and how to resolve the problem?
A VOB object that is not visible because another object with the same name is currently selected by the view. Delete view private version.
What is evil twin and how to resolve the problem?
"Evil Twins" is, two elements of the same name, are created in two different versions of the same directory element.
Advantages of Rational ClearCase over other SCM tool i.e Microsoft Visual Source Safe?
The multisite is the best part of clearcase than any other tool
The beauty of clearcase lies in its conecpts of config spec and views
In CLearcase performance is better supports more data size
What is the name of the Network protocols used by ClearCase?
The protocols used for network communications are TCP (Transmission Control Protocol) and UDP (User Datagram Protocol), which are layered over IP (Internet Protocol). Most processes use TCP, but for optimization some use UDP. The protocol that a ClearCase server process uses is hard coded and cannot be manually configured, changed or disabled
What is the Config Spec?
A config spec is the mechanism that a ClearCase View determines what versions of an element that the user accesses. A config spec is only editable, by default, by the account that created the View. A config spec has a single rule on each line, and the lines are interpreted by ClearCase from the top to the bottom as the order of importance.
What Credentials Manager service do?
ClearCase does not have a built-in authentication mechanism, and makes use of the security and access controls provided by the Windows operating system. The credentials manager Service, cccredmgr, registers the ClearCase group security identifier (SID) at system startup with MVFS.
What are clearcase metadata ?
Metadata is set of constructs and annotations that attach to clearcase objects. It manages you to organize, manipulate and manage those objects. Enables you to find , list. sort and retrieve information
Clearcase : Understanding Config Specs
Posted by
Mahanthesh KN
comments (2)
A config spec is the mechanism that a ClearCase View determines what versions of an element that the user accesses. A config spec is only editable, by default, by the account that created the View. A config spec has a single rule on each line, and the lines are interpreted by ClearCase from the top to the bottom as the order of importance. For example, when you create a new ClearCase View, the default config spec is set to this:
element * CHECKEDOUT
element * /main/LATEST
Each rule basically consists of three parts. First the word "element", second what element to find, and third is the version to access. In this default config spec example, the first rule says to access the checkedout version of the element if the current View has the element checkedout for each element. If the View does not have the element checkedout, then the next rule is interpreted. In this example, the next rule dictates that the View will access the latest version of the element on the /main/ branch. This rule will guarantee to find a version to access, so any further rules, if any existed, will be ignored.
Let’s take a look at this more complicated config spec with example #2:
element /vob/test/a.txt /main/3
element /vob/test/b.txt /main/4 # This is a comment.
#element * /main/LATEST
# The previous line is a comment, thus completely ignored.
element /vob/test/… /main/LATEST
The first rule states to only access the /main/3 version of the element "/vob/test/a.txt". This element may or may not exist, and ClearCase has no verification. Any other elements of a different path will ignore this rule.
The second rule states to only access the /main/4 version of a different element called "/vob/test/b.txt". Note that anything after the first # symbol is a comment and is ignored.
The third and fourth lines are comments, so they will be ignored even though they may have embedded rules.
The fifth line says for all elements in the VOB call "/vob/test", access the latest versions on the /main/ branch, unless a previous rule already selected a version.
Note that there are no rules in this config spec to access any versions in any other VOB, so all other VOBs will be inaccessible with this config spec.
You may want to take a mental break now, since the next example is much more complicated. If you don’t know what are labels or branches yet, I recommend reading the other training web pages first. Here is example #3:
element /vob/training/hockey/… HOCKEY_LABEL
element /vob/training/baseball/… BASEBALL_LABEL
element /vob/training/football/… …/football_branch/LATEST
element /vobs/training/… /main/LATEST
The first line says to access only the versions that have a label called "HOCKEY_LABEL" in the directory called /vobs/training/hockey. Not all files (or sub-directories) in this directory may have this rule, so these elements will not be accessed from this rule. Similarly, the second line says to access only the versions that have a label called "BASEBALL_LABEL" in the directory called /vobs/training/baseball. The third rule says to access the latest versions in the "/vob/training/football" directory on the /football_branch/ branch if that branch exists for each element. Otherwise the fourth rule says to access all other elements that the previous rules did not define to access by accessing the latest versions in the "/vob/training/" directory on the /main/ branch.
Confused yet? Well, it gets MUCH more complicated. Here is example #4:
element /vob/test/a.txt -none
element b.txt -none
element * /main/test/LATEST
element –file * /main/LATEST
element -directory * /main/LATEST
The first rule says to not access any versions of the element "/vob/test/a.txt". The second rule says to not access any versions that have the element name "b.txt" even if multiple files have the same filename in different directories. I strongly to always use the full paths when modifying config specs, otherwise unintended consequences may happen. The third rule says to access all the latest versions on the /main/test/ branch. Well, this is a bad example, because what if the user wanted to access versions on the /test/ branch, but the /test/ branch was not branching from the /main/ branch? For example /main/abc/test/3 would not be seen in this config spec. The better solution for this line would be "element * …/test/LATEST".
The fourth rule says to access the latest versions of all files on the /main/ branch. The fifth rule says to access the latest versions of all directories on the /main/ branch too. The fourth and fifth rules combined are equal to "element * /main/LATEST", but there are sometimes reasons to handle directories and files differently.
Here is most confusing config spec example, and the most likely to be seen in the real world. Here is example #5:
element * CHECKEDOUT
element * …/developers_branch/LATEST
element -file * RELEASED_LABEL -mkbranch developers_branch
element -file * /main/LATEST -mkbranch developers_branch
element * /main/LATEST
The first rule states to access the checkedout version if the current View has the element checkedout. The second rule states to access the latest version on the branch called /developers_branch/ if the branch exists. This is where the software developers typically make their code or documentation changes on their own personal branch. Each developer should have a unique branch for each change they are implementing too. The developer must have already created the branch type manually for this line to work correctly.
If the element is not already being modified on the developer’s branch, then the third rule will access the version for files that were labeled using the label called "RELEASED_LABEL", if the label exists. Furthermore, this is the version that will be branched from if the developer tries to checkout, if this label exists. The fourth rule is the same rule as the third rule, except this is for all files that do not have the label called "RELEASED_LABEL", so that new files can be added to source control and be accessed and modified accordingly. Finally, the fifth rule is for all the remaining elements, such as directories, to access the /main/LATEST versions and checkouts will not be on the developer’s branch.
I hope this explanation was clear.
ver wanted to rollback the clock to see what was in the VOB in the past without using an old label in your Config Spec? Well you can, with the "Time Rules" feature of Config Specs. For instance, let's say you wanted to see how all the VOBs appeared as if it was still 11AM on March 5th, then you can use this config spec:
element * CHECKEDOUT
element * /main/LATEST -time 5-Mar.11:00
There are a lot of options with this "-time" argument. To see the complete list of these "Time Rules", please read the online man page for Config Specs using this command:
cleartool man config_spec
Here is a sneaky shortcut when editing a Config Spec a lot. Don't!
Instead, you can edit your Config Spec only once and have it point to a text file instead.
#element * CHECKEDOUT
include /tmp/config_spec_rules.txt
#element * /main/LATEST
Now you can more easily edit your Config Spec with your favorite editor, since it is now in a text file. This makes automating changes to your Config Spec much simpler too. Keep in mind that whenever editing the included file, the View will need to be alerted of a change using this refresh View command:
cleartool setcs -current
You can mix and match regular Config Spec rules with include rules in any order that you wish. And you can have any number of included files in your Config Spec, however you can not include a file from an include file. I assume this restriction is to prevent a possible infinite loop (i.e. an include file cannot include itself).
Subscribe to:
Posts (Atom)
