Question

How to know an incoming sync packet is inteded for a particular vob?

multitool lspacket -l doesn’t tell for which vob this is intended.

I have several incoming packets intended for my replica but when I import them using this command i am getting the below error:

C:\Program Files\IBM\RationalSDLC\ClearCase\var\shipping\ms_ship\incoming>multitool syncreplica -import sync_usal_unix_2012-11-29T23.00.17-05.00_2296

multitool: Error: Sync. packet C:\Program Files\IBM\RationalSDLC\ClearCase\var\shipping\ms_ship\incoming\sync_usal_unix_2012-11-29T23.00.17-05.00_2296 is not applicable.

Answer 1

Actually, multitool lspacket is the right command to check initially:

The OP vchitta initially thought:

The lspacket gave the below out put which shows that the intended replica name is correct but it doesn’t reveal the VOB details.

multitool lspacket sync_usal_unix_2012-12-01T23.01.06-05.00_19957 
Packet is: C:\Program Files\IBM\RationalSDLC\ClearCase\var\shipping\ms_ship\incoming\sync_usal_unix_20‌​12-12-01T23.01.06-05.00_19957 
Packet type: Update Packet fragment: 1 of 1 
VOB family identifier is: 360ab8c4.661e11d3.a49e.00:01:80:a9:b5:ec 

To which I argued:

Did you search ‘360ab8c4.661e11d3.a49e.00:01:80:a9:b5:ec‘ in the vob registry?
(or simply cleartool lsvob -l)
Is there any other Vob which would have the same uid?
See VOB objects and VOB replica objects.
Yes or no, this is your answer right there.

THE IBM documentation clearly mentions:

Each replica is a VOB, but the VOB object and VOB-replica object are different objects in the VOB database.
Specifically:

• VOB object: The database has a single VOB object.
  This object’s UUID is listed as the VOB family uuid in a lsvob –long listing.
• VOB-replica object (or replica object): The database has a VOB-replica object for each of the VOB’s replicas.
  This object’s UUID is listed as the Vob replica uuid in a lsvob –long listing.

The OP adds:

No.
No vob is having family identifier with the above UUID.
Now I am able to find which vob a packet is intended for with the help of family UUID.
I found this particular packet is for Platfom vob which I didn’t replicated yet.

---

Original answer

See first “Packet is not applicable to any local replicas“

To verify that the host-name property of a VOB replica is wrong, enter the following command:

cleartool describe –fmt "%[replica_host]p\n"
replica:importing-replica-name@VOB-tag

For example:

cleartool describe –fmt "%[replica_host]p\n" replica:newyork@/vobs/tests
manhattan

If the host name is incorrect, use the chreplica command to change it. At the master replica of the importing replica, enter a chreplica command:

multitool chreplica –c "comment" –host new-host
 replica:importing-replica-name@VOB-tag

For example:

multitool chreplica –c "change host name" –host brooklyn
replica:newyork@/vobs/tests
Updated replica information for "newyork".

Send an update packet to the other replicas in the family.

---

You can have multiple causes, as describes in this technote

Cause

• The import command may have been run from a host other than the VOB server.
• The hostname associated with the replica may have changed and MultiSite has not been updated.
• The VOB server may have multiple host names and or multiple network cards and MultiSite is not properly configured to work with them.

Resolving the problem

For cause 1:

Make sure the syncreplica -import command is being run on the VOB server host.
The syncreplica -import command must be run on the VOB server host as it is a server operation.

For cause 2:

Check the hostnames associated with the replica and compare the outputs using the two commands below.
The VOB and the replica should show identical “host” output. If they do not, this is likely to be the problem.
Use the multitool chreplica -host command to resolve the problem.
Review the MultiSite Administrator’s Guide on the topic of chreplica (multitool man chreplica) for more details.

    cleartool lsvob -long <vob tag>
    multitool lsreplica -long <replica-name>

For cause 3:

If the import is in fact being run on the correct server host, check to see how many hostnames that machine has.
Maybe the server has more then one network card, or several aliases.
If there is more than one name, make sure that the alternate_hostnames file exists.

It should contain each and every hostname the machine has, one per line.

Note: The alternate_hostnames file is supported on UNIX® and Linux® only.