Troubleshooting
Problem
Errors such as "Unable to find replica in registry" or "Unable to determine administrative VOBs" or "Trouble finding the global definition" occur when an IBM Rational ClearCase VOB hyperlink between an AdminVOB and its client VOB is broken.
Symptom
SCENARIO:
An AdminVOB has been deleted by mistake. The deletion of the VOB was not performed using the ClearCase command cleartool rmvob or all the VOBs were not available at the time of deletion. After the VOB has been removed lots of different operations related to metadata fail with a cryptic error messages such as:
cleartool: Error: Unable to find replica in registry for VOB with object D:"d3fbde9c.c78e4816.aa15.c6:47:7a:2a:94:37"
cleartool: Error: Unable to locate versioned object base with object id: "d3fbde9c.c78e4816.aa15.c6:47:7a:2a:94:37".
cleartool: Error: Unable to search for process guards
cleartool: Error: Unable to unlock versioned object base "<vobtag>".
Making new metadata (such as a label or a branch) results in the following errors:
% cleartool mklbtype -ordinary XX
cleartool: Error: Unable to find replica in registry for VOB with object ID:"d010b75e.4d1311d0.a11c.00:01:80:82:10:c2"
cleartool: Error: Unable to locate versioned object base with object id: "d010b75e.4d1311d0.a11c.00:01:80:82:10:c2".
cleartool: Error: Unable to determine administrative VOBs of VOB "\sys".
cleartool: Error: Error detected by process execution manager
cleartool: Error: Process execution failure - aborting...
cleartool: Error: Unable to create label type "XX".
M:\akemim_view\ch>cleartool mkbrtype -ordinary XX
Comments for "XX":
.
cleartool: Error: Unable to find replica in registry for VOB with object ID:"2359e77a.b13d4b73.8ae1.27:9a:7d:95:3b:6a"
cleartool: Error: Unable to locate versioned object base with object id: "2359e77a.b13d4b73.8ae1.27:9a:7d:95:3b:6a".
cleartool: Error: Unable to search for process guards
cleartool: Error: Unable to create branch type "XX".
Describing existing metadata (such as a branch) results in the following error:
cleartool: Error: Unable to find replica in registry for VOB with object ID:"e64a82f8.80124520.bf90.cc:0c:0c:b0:1f:78"
cleartool: Error: Unable to locate versioned object base with object id:"e64a82f8.80124520.bf90.cc:0c:0c:b0:1f:78".
cleartool: Error: Unable to find replica in registry for VOB with object ID:"e64a82f8.80124520.bf90.cc:0c:0c:b0:1f:78"
cleartool: Error: Unable to locate versioned object base with object id:"e64a82f8.80124520.bf90.cc:0c:0c:b0:1f:78".
cleartool: Error: Trouble finding the global definition for local type "dmm1".
Cause
These errors are all related to the same problem. There was an established AdminVOB hyperlink created between the VOBs and that hyperlink has been severed.
Resolving The Problem
Example - non-working environment (VOB) Removing the broken hyperlink on the VOB Example - non-working environment (METADATA) Removing the broken hyperlink on the metadata type Recreate a new admin VOB and relink the type in the AdminVOB
About AdminVOBs
- An AdminVOB is a normal VOB that will be principally used to store globally defined metadata types (branch, label, attribute, elements and hyperlinks).
Note: Triggers are omitted. Review technote 1148828 for more information.
- AdminVOB and its corresponding client VOBs are linked together using hyperlinks.
Note: A hyperlink also exists on the local copy of the global types residing in both VOBs.
- Each VOB can only have a single AdminVOB.
- An AdminVOB can be linked to another AdminVOB.
More information about Administrative VOBs can be found in the ClearCase Administrator's Guide under the topic of Use of Administrative VOBs.
About Broken Hyperlinks
When an AdminVOB (or client VOB) is incorrectly removed, all of the associated hyperlinks are left dangling and prevent normal ClearCase operations.
Below is an example on how to find and fix this problem.
Note: For this example two VOBs will be used: AdminVOB and ClientVOB.
Note for MultiSite users
The following example relates to a VOB that is NOT replicated. If you are using MultiSite, understand the general concepts are the same; however, you will need to factor in mastership and synchronization procedures during the time you will perform the fix.
The below cleartool describe output of a VOB object illustrates a functional AdminVOB hyperlink:
N:\>cleartool describe -long vob:\AdminVOB
versioned object base "\AdminVOB"
created 25-Jan-06.14:54:19 by NL55689.None@IBM-5F837AA8819
"AdminVOB"
VOB family feature level: 4
VOB storage host:pathname "Ibm-5f837aa8819:C:\CCSHARE\VOB\AdminVOB.vbs"
VOB storage global pathname "\\Ibm-5f837aa8819\CCSHARE\VOB\AdminVOB.vbs"
database schema version: 54
VOB ownership:
owner IBM-5F837AA8819\NL55689
group IBM-5F837AA8819\None
Attributes:
FeatureLevel = 4
Hyperlinks:
AdminVOB@42@\ClientVOB <- vob:\ClientVOB
And the same is true for the client VOB:
N:\>cleartool describe -long vob:\ClientVOB
versioned object base "\ClientVOB"
created 25-Jan-06.14:54:57 by NL55689.None@IBM-5F837AA8819
"ClientVOB"
VOB family feature level: 4
VOB storage host:pathname "Ibm-5f837aa8819:C:\CCSHARE\VOB\ClientVOB.vbs"
VOB storage global pathname
"\\Ibm-5f837aa8819\CCSHARE\VOB\ClientVOB.vbs"
database schema version: 54
VOB ownership:
owner IBM-5F837AA8819\NL55689
group IBM-5F837AA8819\None
VOB holds objects from the following views:
Ibm-5f837aa8819:C:\CCSHARE\VIEW\General_view.vws [uuid
f51e15ce.827c4cad.bf15.82:45:97:7a:83:1b]
Attributes:
FeatureLevel = 4
Hyperlinks:
AdminVOB@42@\ClientVOB -> vob:\AdminVOB
There is an AdminVOB hyperlink in both of them (one going TO and the other one coming FROM the AdminVOB). This is how client VOBs and Admin VOBs find each other.
Note: In these VOBs there is also one branch type (MyBranch) that will be used for the example.
First let's have a look in the AdminVOB for the branch type by listing all of the branch types and describing the branch of interest:
N:\AdminVOB>cleartool lstype -local -l -kind brtype
branch type "MyBranch"
15-Feb-06.16:23:29 by NL55689.None@IBM-5F837AA8819
owner: IBM-5F837AA8819\NL55689
group: IBM-5F837AA8819\None
scope: global
constraint: one version per element
N:\AdminVOB>cleartool describe -local -long brtype:MyBranch
branch type "MyBranch"
created 15-Feb-06.16:23:29 by NL55689.None@IBM-5F837AA8819
owner: IBM-5F837AA8819\NL55689
group: IBM-5F837AA8819\None
scope: global
constraint: one version per element
Note: The usage of the -local option in the above commands. This is necessary to obtain the information on the type object from the VOB where the command was run (or the one that you would specify if using the extended object name). Without the -local switch, the describe would query the AdminVOB first and report the information from there.
As reported, we have one branch type called MyBranch, and this type is a global one.
A global type indicates that the metadata was created in the AdminVOB and will be available to all client VOBs linked to it (the type definition will be created automatically in the client from the global definition if needed).
The information from the client VOB clearly indicates the use of an Admin VOB:
N:\ClientVOB>cleartool lstype -local -long -kind brtype
branch type "MyBranch"
15-Feb-06.16:26:16 by NL55689.None@IBM-5F837AA8819
"Automatically created branch type from global definition in VOB
"\AdminVOB"."
owner: IBM-5F837AA8819\NL55689
group: IBM-5F837AA8819\None
scope: this VOB (local copy of global type)
constraint: one version per element
N:\ClientVOB>cleartool describe -local -long brtype:MyBranch
branch type "MyBranch"
created 15-Feb-06.16:26:16 by NL55689.None@IBM-5F837AA8819
"Automatically created branch type from global definition in VOB "\AdminVOB"."
owner: IBM-5F837AA8819\NL55689
group: IBM-5F837AA8819\None
scope: this VOB (local copy of global type)
constraint: one version per element
Hyperlinks:
GlobalDefinition@49@\ClientVOB -> brtype:MyBranch@\AdminVOB
The type located in the client VOB is shown as a 'local copy of global type' and also has an hyperlink to the global type definition in the AdminVOB.
How does this work
Let's assume that the type doesn't exist in the client VOB.
Issue the cleartool mkbranch command to create a branch instance named MyBranch.
N:\ClientVOB>cleartool mkbranch MyBranch file.txt
Creation comments for "file.txt@@\main\MyBranch":
.
Automatically created branch type "MyBranch" from global definition in VOB "\AdminVOB".
Created branch "MyBranch" from "file.txt" version "\main\1".
cleartool: Warning: Version checked out ("\main\MyBranch\0") is different from version selected by view before checkout
("\main\1").
Checked out "file.txt" from version "\main\MyBranch\0".
Step by step under the hood:
- ClearCase looks in the current VOB for a local branch type definition (either a local type, or a local copy of a global type).
- If it exists:
- The client checks the parent global type for "process guards" (currently only used for UCM stream associations, but this check is made against all branch, label, an other types for backward compatibility reasons).
- If no "process guards" are found, or those guards allow the branch to be created (checkout in UCM branch type in view connected to the right stream), the client creates the branch from the existing local type.
- If a local copy does not exist, the client will look for an AdminVOB hyperlink.
- If the AdminVOB hyperlink exists and points to an existing VOB:
- the client searches that for a global type definition with the same name as the branch being requested.
- If the global type exists, it will be examined for "process guards" as described above, if not, you will see the error in step 5 below.
- If no "process guards" block the mkbranch operation, then a local copy of the global type will be made in the VOB where the mkbranch operation was requested and the requested branch will be created.
- If no AdminVOB hyperlink exists, the client reports the following error:
cleartool: Error: branch type "{name}" not found in VOB "\mkvobtest" and no global type definition can be found.
cleartool: Error: Unable to create branch "{name}" from "." version "{parent version ID}".
NON-WORKING ENVIRONMENT (VOB)
The AdminVOB has been removed without cleaning the link.
- One common reason this can occur is that its storage has been manually removed by mistake or the machine on which it has been stored is no longer active or available.
- A second common reason this can occur is the common misjudgment that it is no longer needed or used due to its lack of activity or stored data, which results in a desicion to remove the VOB.
The AdminVOB is gone, execution of ClearCase commands will result in the following error:
N:\ClientVOB>cleartool unlock vob:\ClientVOB
cleartool: Error: Unable to find replica in registry for VOB with object
D:"d3fbde9c.c78e4816.aa15.c6:47:7a:2a:94:37"
cleartool: Error: Unable to locate versioned object base with object id:
"d3fbde9c.c78e4816.aa15.c6:47:7a:2a:94:37".
cleartool: Error: Unable to search for process guards
cleartool: Error: Unable to unlock versioned object base "\ClientVOB".
The first thing to check for is broken links of the type AdminVOB.
N:\ClientVOB>cleartool describe -long vob:\ClientVOB
versioned object base "\ClientVOB"
created 25-Jan-06.14:54:57 by NL55689.None@IBM-5F837AA8819
"ClientVOB"
VOB family feature level: 4
VOB storage host:pathname "Ibm-5f837aa8819:C:\CCSHARE\VOB\ClientVOB.vbs"
VOB storage global pathname
"\\Ibm-5f837aa8819\CCSHARE\VOB\ClientVOB.vbs"
database schema version: 54
VOB ownership:
owner IBM-5F837AA8819\NL55689
group IBM-5F837AA8819\None
VOB holds objects from the following views:
Ibm-5f837aa8819:C:\CCSHARE\VIEW\General_view.vws [uuid
f51e15ce.827c4cad.bf15.82:45:97:7a:83:1b]
Attributes:
FeatureLevel = 4
Hyperlinks:
AdminVOB@53@\ClientVOB -> <object not available>
The last part of the output is reporting an object not available. This is the broken link. Note: The same error would be reported for local copy of global types:
N:\ClientVOB>cleartool describe -local -long brtype:MyBranch
branch type "MyBranch"
created 15-Feb-06.16:26:16 by NL55689.None@IBM-5F837AA8819
owner: IBM-5F837AA8819\NL55689
group: IBM-5F837AA8819\None
scope: this VOB (local copy of global type)
constraint: one version per element
Hyperlinks:
GlobalDefinition@54@\ClientVOB -> <object not available>
Removing the broken hyperlink on the VOB
If the VOB was locked, unlock it.
If the unlock command fails, you will need to remove the link in order to unlock the VOB.
Use the cleartool checkvob command with the -hlinks option as follows:
N:\ClientVOB>cleartool checkvob -hlink vob:\ClientVOB
Unable to determine if the following hyperlink is intact.
AdminVOB@53@\ClientVOB vob:\ClientVOB -> <object not available>
Delete it? [no] yes
cleartool: Error: Unable to find replica in registry for VOB with object
D:"d3fbde9c.c78e4816.aa15.c6:47:7a:2a:94:37"
cleartool: Error: Unable to locate versioned object base with object id:
"d3fbde9c.c78e4816.aa15.c6:47:7a:2a:94:37".
Removed hyperlink "AdminVOB@53@\ClientVOB vob:\ClientVOB -> <object not available>".
The broken link has been removed.
N:\ClientVOB>cleartool describe -long vob:\ClientVOB
versioned object base "\ClientVOB"
created 25-Jan-06.14:54:57 by NL55689.None@IBM-5F837AA8819
"ClientVOB"
VOB family feature level: 4
VOB storage host:pathname "Ibm-5f837aa8819:C:\CCSHARE\VOB\ClientVOB.vbs"
VOB storage global pathname
"\\Ibm-5f837aa8819\CCSHARE\VOB\ClientVOB.vbs"
database schema version: 54
VOB ownership:
owner IBM-5F837AA8819\NL55689
group IBM-5F837AA8819\None
VOB holds objects from the following views:
Ibm-5f837aa8819:C:\CCSHARE\VIEW\General_view.vws [uuid
f51e15ce.827c4cad.bf15.82:45:97:7a:83:1b]
Attributes:
FeatureLevel = 4
NON-WORKING ENVIRONMENT (METADATA)
A look at the previous branch type:
N:\ClientVOB>cleartool lstype -local -long -kind brtype
branch type "MyBranch"
15-Feb-06.16:26:16 by NL55689.None@IBM-5F837AA8819
owner: IBM-5F837AA8819\NL55689
group: IBM-5F837AA8819\None
scope: this VOB (local copy of global type)
constraint: one version per element
N:\ClientVOB>cleartool describe -local -long brtype:MyBranch
branch type "MyBranch"
created 15-Feb-06.16:26:16 by NL55689.None@IBM-5F837AA8819
owner: IBM-5F837AA8819\NL55689
group: IBM-5F837AA8819\None
scope: this VOB (local copy of global type)
constraint: one version per element
Hyperlinks:
GlobalDefinition@54@\ClientVOB -> <object not available>
The link is still broken for the type.
Note: Removing the general AdminVOB hyperlink does not fix the GlobalDefinition link in the local copy of the client VOB.
From here there are two possible solutions in order to correct the metadata type:
- Clean the broken link on the metadata type. This will transform all the broken 'local copy of global type' into normal type and allow the use of them. But there will be no concept of AdminVOB for them anymore.
- Recreate a new Admin VOB and relink the type in the AdminVOB.
Note: This step must be performed after step one above is complete.
Removing the broken hyperlink on the metadata type
First the type with the broken link has to be identified. This will be the one with the object not available:
N:\ClientVOB>cleartool describe -local -long brtype:MyBranch
branch type "MyBranch"
created 15-Feb-06.16:26:16 by NL55689.None@IBM-5F837AA8819
owner: IBM-5F837AA8819\NL55689
group: IBM-5F837AA8819\None
scope: this VOB (local copy of global type)
constraint: one version per element
Hyperlinks:
GlobalDefinition@54@\ClientVOB -> <object not available>
Remove the link (same as for the VOB above):
N:\ClientVOB>cleartool checkvob -hlink brtype:MyBranch@\ClientVOB
Unable to determine if the following hyperlink is intact.
GlobalDefinition@54@\ClientVOB brtype:MyBranch@\ClientVOB -> <object not
available>
Delete it? [no] yes
cleartool: Error: Unable to find replica in registry for VOB with object
D:"d3fbde9c.c78e4816.aa15.c6:47:7a:2a:94:37"
cleartool: Error: Unable to locate versioned object base with object id:
"d3fbde9c.c78e4816.aa15.c6:47:7a:2a:94:37".
Removed hyperlink "GlobalDefinition@54@\ClientVOB
brtype:MyBranch@\ClientVOB -> <object not available>".
The link has been removed. The type is now a local version only:
N:\ClientVOB>cleartool describe -local -long brtype:MyBranch
branch type "MyBranch"
created 15-Feb-06.16:26:16 by NL55689.None@IBM-5F837AA8819
owner: IBM-5F837AA8819\NL55689
group: IBM-5F837AA8819\None
scope: this VOB (ordinary type)
constraint: one version per element
This will need to be repeated for ALL metadata type with the broken link.
Recreate a new Admin VOB and relink the type in the AdminVOB
A working and active AdminVOB is required.
Create a new VOB if required (here we will use the tag \AdminVOB3).
Then link it as an AdminVOB to the client VOB:
N:\ClientVOB>cleartool mkhlink AdminVOB vob:\ClientVOB vob:\AdminVOB3
Created hyperlink "AdminVOB@55@\ClientVOB".
Note: The cleartool mkhlink command must be run from the client VOB . It will create a new hyperlink of type AdminVOB. A cleartool describe on the VOB object from the client VOB and the new AdminVOB will show the new link:
N:\ClientVOB>cleartool describe -long vob:\ClientVOB
versioned object base "\ClientVOB"
created 25-Jan-06.14:54:57 by NL55689.None@IBM-5F837AA8819
"ClientVOB"
VOB family feature level: 4
VOB storage host:pathname "Ibm-5f837aa8819:C:\CCSHARE\VOB\ClientVOB.vbs"
VOB storage global pathname
"\\Ibm-5f837aa8819\CCSHARE\VOB\ClientVOB.vbs"
database schema version: 54
VOB ownership:
owner IBM-5F837AA8819\NL55689
group IBM-5F837AA8819\None
VOB holds objects from the following views:
Ibm-5f837aa8819:C:\CCSHARE\VIEW\General_view.vws [uuid
f51e15ce.827c4cad.bf15.82:45:97:7a:83:1b]
Attributes:
FeatureLevel = 4
Hyperlinks:
AdminVOB@55@\ClientVOB -> vob:\AdminVOB3
N:\>cleartool describe -long vob:\AdminVOB3
versioned object base "\AdminVOB3"
created 15-Feb-06.17:09:04 by NL55689.None@IBM-5F837AA8819
VOB family feature level: 4
VOB storage host:pathname "Ibm-5f837aa8819:C:\CCSHARE\VOB\AdminVOB3.vbs"
VOB storage global pathname
"\\Ibm-5f837aa8819\CCSHARE\VOB\AdminVOB3.vbs"
database schema version: 54
VOB ownership:
owner IBM-5F837AA8819\NL55689
group IBM-5F837AA8819\None
Attributes:
FeatureLevel = 4
Hyperlinks:
AdminVOB@55@\ClientVOB <- vob:\ClientVOB
We now have a working Admin VOB for this client VOB. Now to get back the situation as before, we need to convert the local type in each client VOB to a local copy of a global type that is located in the Admin VOB.
In the Admin VOB there is actually no type defined:
N:\AdminVOB3>cleartool lstype -local -long -kind brtype
<empty>
But in the client VOB we have a type definition :
N:\ClientVOB>cleartool describe -local -long brtype:MyBranch
branch type "MyBranch"
created 15-Feb-06.16:26:16 by NL55689.None@IBM-5F837AA8819
owner: IBM-5F837AA8819\NL55689
group: IBM-5F837AA8819\None
scope: this VOB (ordinary type)
constraint: one version per element
Create a global type using the information from the client and link them together:
N:\AdminVOB3>cleartool mkbrtype -global -acquire MyBranch
Comments for "MyBranch":
.
Created branch type "MyBranch".
Note: The -acquire option will create a global type in the current VOB by reading the existing type in the client VOB.
We can check and see that the type created is global:
N:\AdminVOB3>cleartool describe -local -long brtype:MyBranch
branch type "MyBranch"
created 15-Feb-06.18:31:56 by NL55689.None@IBM-5F837AA8819
owner: IBM-5F837AA8819\NL55689
group: IBM-5F837AA8819\None
scope: global
constraint: one version per element
Hyperlinks:
GlobalDefinition@60@\ClientVOB <- brtype:MyBranch@\ClientVOB
And in the client we got the link back:
N:\ClientVOB>cleartool describe -local -long brtype:MyBranch
branch type "MyBranch"
created 15-Feb-06.16:26:16 by NL55689.None@IBM-5F837AA8819
owner: IBM-5F837AA8819\NL55689
group: IBM-5F837AA8819\None
scope: this VOB (local copy of global type)
constraint: one version per element
Hyperlinks:
GlobalDefinition@60@\ClientVOB -> brtype:MyBranch@\AdminVOB3
You just need to perform the same operation for the other type with the
same problem.
Scripting Hints
Doing all of this can be very lengthy in a case where numerous metadata types are broken, especially when it has to be done in all VOBs.
This could be scripted to automate the process.
In order to do so you will need to obtain the following information:
In the client VOB:
- Get the full list of metadata type that need to be checked/fixed.
Run in each VOB:
cleartool lstype -local -s -kind <type> -invob \ClientVOB
Note: Where <type> would be brtype, lbtype, attype.
- For each object returned run:
cleartool checkvob -force -hlink <type>:<name>@\ClientVOB
Note: Where <name> is the name returned from step 1.
- Run for each name returned from step 1:
cleartool mkbrtype -global -acquire <name>
Related Information
[{"Product":{"code":"SSSH27","label":"Rational ClearCase"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"VOB","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF015","label":"IRIX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"7.0;7.0.1;7.1;7.1.2;8.0;8.0.1","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}},{"Product":{"code":"SSSH27","label":"Rational ClearCase"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"VOB","Platform":[{"code":"","label":""}],"Version":"","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Was this topic helpful?
Document Information
Modified date:
19 February 2019
UID
swg21231183