This section describes commands you can use to troubleshoot failed mastership requests, and lists error messages and their meanings.
To determine which replica masters a branch or branch type:
cleartool describe –fmt "%[master]p\n" file1.txt@@\main boston_hub@\dev
cleartool describe –fmt "%[master]p\n" brtype:main@/vobs/doc boston_hub@/vobs/doc
To determine whether a mastership request will succeed:
multitool reqmaster –nc –list file1.txt@@/main multitool: Error: The following errors will be encountered multitool: Error: file1.txt@@/main Request Mastership remote "reqmaster" operation (host "taronga") would fail: You do not have permission to request mastership from the sibling replica.
To list the event history of a branch or branch type and determine who has requested its mastership, use the lshistory –minor –fmt command:
cleartool lshistory –min –fmt "%n\t%o\n%c" file.fm@@/main file.fm@@/main chmaster Reqmaster changed master replica from "boston_hub" to "buenosaires". Requester: user "PURPLEDOC\fangio" in domain "PURPLEDOC" on host "mardelplata" file.fm@@/main chmaster Reqmaster changed master replica from "tokyo" to "boston_hub". Requester: user "PURPLEDOC\susan" in domain "PURPLEDOC" on host "minuteman" file.fm@@/main chmaster Reqmaster changed master replica from "bangalore" to "tokyo". Requester: user "PURPLEDOC\masako" in domain "PURPLEDOC" on host "shinjuku" file.fm@@/main chmaster Reqmaster changed master replica from "sanfran_hub" to "bangalore". Requester: user "PURPLEDOC\kumar" in domain "PURPLEDOC" on host "ramohalli" ...cleartool lshistory –min –fmt "%n\t%o\n%c" brtype:main@/vobs/doc main chmaster Reqmaster changed master replica from "sanfran_hub" to "boston_hub". Requester: user "PURPLEDOC\susan" in domain "PURPLEDOC" on host "minuteman" main chmaster Reqmaster changed master replica from "tokyo" to "sanfran_hub". Requester: user "PURPLEDOC\jcole" in domain "PURPLEDOC" on host "goldengate" main chmaster Reqmaster changed master replica from "bangalore" to "tokyo". Requester: user "PURPLEDOC\masako" in domain "PURPLEDOC" on host "shinjuku" ...
Table 15 describes error messages you may see when you enable or disable requests at the replica level, work with the ACL, and allow or deny requests at the branch type or branch level. Table 16 describes error messages associated with mastership requests.
Errors that occur during the mastership request process, including errors that occur during the synchronization export, are written to the msadm log file. To view it, use the cleartool getlog command or the ClearCase Administration Console (Windows).
Message
|
Meaning of message and action to take
|
---|---|
The process that checks the ACL could not determine whether you have read or write permissions on the ACL. Check the msadm and albd log files on the client and server hosts and try the command again later.
|
|
You do not have permission to edit the ACL.
To edit the ACL, you must be VOB owner, root (UNIX), a member of the ClearCase administrators group (Windows), or have write permission on the ACL.
|
|
Your client computer could not retrieve the ACL from the VOB server host. There may be a network connection problem. Check the msadm and albd log files on the client and server hosts and try the command again later.
|
|
The command could not find the object. Check the spelling and syntax of the object selector. In a dynamic view context, mount the VOB and try the command again.
|
|
Specify a branch or branch type.
Examples of branch specifications:
/vobs/dev/acc.c@@/main (UNIX)
\doc\stage.pl@@\main\debug (Windows)
Examples of branch type specifications:
brtype:main
brtype:boston_main@/vobs/dev (UNIX) brtype:v1.0_bugfix@\tests (Windows) |
|
Specify only one VOB selector.
|
|
Specify a VOB selector. For example:
vob:/vobs/dev (UNIX)
vob:\tests (Windows) |
|
The VOB family feature level is less than 2.
If all replicas in the VOB family are at feature level 2 or greater, raise the family feature level.
If any replica in the VOB family has a feature level less than 2, ask the administrator of that replica to upgrade to a newer version of Rational ClearCase (if necessary), raise the feature level of the replica, and send an update packet to the sibling replicas. Then raise the family feature level.
|
|
A replica must be self-mastering for you to enable requests for mastership in that replica. See Transferring Mastership of a Replica Object.
|
|
For you to allow or deny mastership requests for a branch, your current replica must master the branch.
Determine which replica masters the branch and ask the administrator of the replica to change mastership of the branch to your replica.
|
|
For you to allow or deny mastership requests for a branch type, your current replica must master the branch type.
Determine which replica masters the branch type and ask the administrator of the replica to change mastership of the branch type to your replica.
|
|
To enable requests at the replica level, use the –enable option and specify a VOB selector. To deny or allow requests for all instances of a branch type, use the –deny or –allow option with the –instances option and specify a branch type selector.
|