| This technote explains why the error, ccweb: Error: Master replica of branch "\main" is "remote-site", may occur when using IBM® Rational® ClearCase® Remote Client even though the unreserved, nonmastered checkout preference is selected. | | | | Symptom | | In the ClearCase Remote Client (CCRC) 7.0.1, there is a feature under Preferences, Always checkout unreserved and nonmastered for replicated elements, that can be set as the default behavior.
However, even with that option selected, the following errors are still being reported: - Unable to checkout "C:\ccweb\NL60989\NL60989_webview\ramp\test"
Problems performing checkout.
- ccweb: Error: Unable to perform operation "checkout" in replica "ralf2"
ccweb: Error: Master replica of branch "\main" is "ming".
ccweb: Error: Unable to check out "C:\ccweb\NL60989\NL60989_webview\ramp
| | |
|
 |
|
| Cause |
CCRC does not recognize the VOB as being replicated, which is a requirement for the checkout request to be successful.
CCRC only sends the request for a nonmastered checkout, if it believes the VOB to be replicated.
To verify if a VOB is replicated, CCRC uses the entry for the VOB in the ClearCase registry, which should have (replicated) at the end of it.
Note: The setting of the VOB's (replicated) attribute value was first implemented in ClearCase MultiSite version 2003.06.14.
Cause 2
Another cause is due to a known defect APAR PK57433 where unreserved and nonmastered checkout falls back to unreserved, mastered checkout.
This happens ONLY with - Multi-level VOB tags (on UNIX® or Linux®). For example /vobs/test
- Only when double clicking the file in the Details Windows
|
| |
|
| Diagnosing the problem |
| You can check the registry on a native client using cleartool lsvob to see if the replicated attribute is set or not for the VOB that is reporting the problem.
In the below example, we can see that the replicated attribute is set for the \abc-vob VOB, but is not set for the \ramp, yet both of these VOBs are actually replicated.
Example:
> cleartool lsvob
* \ramp \\scorpio-I\data\clearcase_storage\vobs\ramp.vbs private
* \abc-vob \\Scorpio-i\data\clearcase_storage\vobs\abc-vob.vbs private (replicated)
In the case with the issue the entry looks like:
\ramp \\scorpio-I\data\clearcase_storage\vobs\ramp.vbs private
The correct entry would look like:
\ramp \\scorpio-I\data\clearcase_storage\vobs\ramp.vbs private (replicated)
- Check the CCRC client Preferences to verify that the preference, Always checkout unreserved and nonmastered for replicated elements, is selected:
|
| |
|
| Resolving the problem |
| Solution for the first Cause The replicated attribute for the VOB reporting the error needs to be set in the Rational ClearCase registry. Either of the 2 options below can be performed to resolve the issue. - Re-register the VOB:
cleartool register -vob -replace
OR
- Run the rgy_upgrade script to set the (replicated) attribute.
Example:
Windows:
On a ClearCase replica server, run the following command for each replicated VOB:
\bin\rgy_upgrade.exe -tag vob-tag [...]
UNIX/Linux:
On a ClearCase replica server, run the following command for each replicated VOB:
/etc/rgy_upgrade -tag vob-tag [...]
Alternate Option
If there are many VOBs on the server that need to be updated, you can use the following syntax to update all VOBs on the current host rather than specifying each VOB-tag individually.
UNIX/Linux: /etc/rgy_upgrade -vobs
Windows: \bin\rgy_upgrade.exe -vobs
For more information About rgy_upgrade, refer to technote 1207026.
Solution for Cause 2 The defect has not been resolved.
WORKAROUND:
Use the Navigator Window (expanding directories) to browse through Directory tree.
Note: If the error has already occurred, disconnect and then reconnect the CCRC client from the server to reset.
|
No comments:
Post a Comment