Technical Bulletin Number 39 - 02/05/01

TO: All Sites Using ClearCase MultiSite
FROM: Customer Support
DATE: 02/05/01
SUBJECT: Technical Bulletin Number 39

Problem 1: Inadvertent Change of Ownership-Preservation Property and Loss of Information Can Be Caused By Use of chreplica -host Command

A customer has reported ClearCase MultiSite defect CMBU00046719, which can cause import failures that require assistance from Rational Support to resolve. If you run a multitool chreplica -host command on a replica whose VOB family is at feature level 1 and you do not specify -preserve or -npreserve, the value of the ownership-preservation property can be incorrect in the oplog entry for the operation. When this oplog entry is imported at other replicas in the family, the ownership-preservation property is changed at those replicas.

The symptom of this problem is a replica whose ownership-preservation property changes inexplicably. The problem may be discovered when import of a packet to a replica that is supposed to be non-ownership-preserving fails with an error message like the following:

multitool: Error: Can't create object with group (group-identifier) that is not in the VOB's group list. 
multitool: Error: Unable to replay oplog entry oplog-number
: error detected by ClearCase subsystem.

This problem can cause import failures or loss of ownership change information.

The workaround is to specify -preserve or -npreserve when you enter a chreplica -host command.

This defect is fixed with a patch, which you must install on all client machines and all VOB replica server hosts.

If this problem has already occurred, there are several possible scenarios and corresponding resolutions:

• If the importing replica is self-mastering, enter the following command at the importing replica, specifying either -preserve or -npreserve as appropriate:

multitool chreplica -host importing-replica-hostname { -preserve | -npreserve } replica-selector

• If the importing replica is not self-mastering, but can import successfully from the mastering replica, enter the following command at the master replica, specifying either -preserve or -npreserve as appropriate, and then send an update packet to the importing replica:

multitool chreplica -host importing-replica-hostname { -preserve | -npreserve } replica-selector

• If the importing replica is not self-mastering and cannot import packets from the master replica, use one of the following methods to fix the problem:
  • Contact Rational Support to obtain a special tool to change the importing replica's ownership-preservation property to non-preserving. When you use this tool, you do not have to replace the replica.
  • Replace the importing replica, following the guidelines in the ClearCase MultiSite Manual.

NOTE: Because of the difficulty of recovering from this problem in non-self-mastering replicas, we recommend that you make all replicas self-mastering whenever possible.

Problem 2: Replica Divergence Can Occur When Preoperation Triggers Fire on Checked-Out Versions

A customer has reported ClearCase MultiSite defect CMBU00047828, which was introduced in Release 4.0 and can cause metadata divergence when pre-operation triggers for certain operations check in the object being modified. The effect of this problem is that metadata you apply at a replica may not be applied at other replicas in the VOB family.

This problem occurs only if all of the following conditions are true:

• You have pre-operation triggers for mklabel, mkattr, or mkhlink operations
• A user executes one of those operations on a checked-out version: the checked-out version is the object to which the attribute or label is to be applied, or the checked-out version is the source or destination of the hyperlink
• The trigger checks in the version before the mklabel, mkattr, or mkhlink operation resumes

If all of the conditions are true, the oplog for the metadata creation contains the OID of the checked-out version, which may not be the same as the OID of the checked-in version. If the OIDs are not identical, the metadata will not be applied to the checked-in version at other replicas in the VOB family.

The following symptoms may occur as a result of this problem:

• A build at a sibling replica may fail because a label is missing or is not on the correct version.
• An import at a sibling replica may fail after a label, attribute, or hyperlink is removed at the original replica.

This defect will be fixed in an upcoming patch, which you must install on all client machines and all VOB replica server hosts. After you install the patch, reapply the metadata to the affected versions. If you need assistance, contact Rational Support.

Any Questions?

Please contact Rational Support