If syncreplica –import determines that a packet is not applicable, it does not print the reason. Also, syncreplica –import uses different criteria than the lspacket command does to determine whether a packet is applicable. Therefore, lspacket may show that a packet is applicable even if syncreplica will not import it.

If a single version's cleartext is larger than the value specified for –maxsize, syncreplica creates the packet and prints a warning message. The –maxsize value is ignored for the packet creation; the packet is at least as large as the file and also includes header information.

When multiple imports occur simultaneously, the following error message may be displayed:

multitool: Error: Database identifier (dbid) not found in database: “VOB-tag”.
...
op= mkhlink

This problem occurs when one update packet includes an operation that attempts to create a hyperlink and another packet includes an operation that removes an object at either end of the hyperlink.

Workaround: Retry the import. To prevent multiple simultaneous imports, use the sync_receive script.

When two or more imports occur simultaneously at a replica, the following error message may be displayed:

multitool: Error: Type manager “text_file_delta” failed delete_branches_versions operation

Workaround: Retry the import. To prevent multiple simultaneous imports, use the sync_receive script.

When a replica is restored using optimization (that is, it does not exchange packets with all other replicas in the VOB family), the special restorereplica oplog entry can be deleted prematurely at the replicas that exchanged updates with the restored replica. In order for all replicas in the VOB family to reflect the correct state of the restored replica, they all must receive the restorereplica oplog entry in an update packet.

For example, assume that replica evanston synchronizes daily with replica paris, paris synchronizes weekly with replica osaka, and osaka synchronizes monthly with evanston:

The administrator at evanston restores the replica from backup and enters the restorereplica command. Because evanston and paris exchange updates so frequently, the evanston administrator decides to optimize the restoration; after the update packet from paris is received and processed at evanston, the administrator enters the restorereplica –override command to complete restoration at evanston. At this point, the special restorereplica oplog entry is deleted at evanston, and the next time paris receives and processes an update packet, the oplog entry is deleted there. However, if paris does not send an update packet to osaka before deleting the oplog entry, osaka will have an inconsistent view of evanston's state.

The symptom of this problem is that the restored replica cannot import update packets sent from replicas that did not receive the restorereplica oplog entry. Imports fail with messages like the following:

multitool: Error: Replica incarnation for “evanston” is old: 12/31/69 19:00:00, should be 09/08/97 15:15:41
multitool: Error: Cannot apply sync. packet

If this problem occurs, contact Customer Support.

When you use syncreplica –import –receive –sclass to import only packets associated with a specific storage class, syncreplica also processes packets in the default storage bay.

Workaround: Use the sync_receive script to import packets.

If the export phase of a mkreplica command is interrupted and the replica-creation packet is not transferred to the new site, the packet is not deleted.

Workaround: Remove the packet and enter the mkreplica –export command again.

When you remove a replica, the rmreplica command renames the replica object. However, the rename operation is not recorded in the operation log, so migration-mode replicas do not rename the replica object automatically. Replicas not in migration mode rename the replica when they replay the rmreplica oplog entry.

Workaround: Explicitly rename the removed replica. For example, if a replica named natick was removed:

multitool rename replica:natick.deleted natick.deleted.old 

Note: This is not an issue when removing the second-to-last replica in a VOB family, which disables replication in the VOB and deletes all replica objects except for the current replica object.

If a syncreplica –import command fails with a message like multitool: Error: Read from input stream failed: No such file or directory, the packet is corrupted.

Workaround: Delete the packet, ask the administrator at the sending site to re-create the packet and send it again, and then import it.

Using lsepoch and chepoch to recover a lost packet does not work if that packet included both a mkreplica operation and oplogs from that new replica. The reason is that the lsepoch output (at the replica that did not receive the packet) will not contain any information about the new replica, and the chepoch command at the sending replica modifies the epoch table according to the information in the lsepoch output.

For example:

The chepoch command does not reset the column for Replica C to zero. Therefore, Replica A's epoch table incorrectly shows that Replica B received the mkreplica operation for Replica C and all the work Replica C has done.

Workaround: Reset the epoch numbers manually. For example:

multitool chepoch –force B A=586 B=985 C=0 
Epoch row successfully set.

If a VOB is locked and there is an exception list (that is, the –nusers option was used), syncreplica –import ignores the lock.

In the MultiSite Control Panel, if you select the Use Default Expiration check box for a storage class, the value displayed in the Packet Expiration box is -1. To display the actual value, display the –default class. If you clear the Use Default Expiration check box, you must change the Packet Expiration value to a number equal to or greater than 0. Otherwise, the Use Default Expiration check box is selected when you click OK.

An automatically generated comment for a directory checkout is not replicated in the following situation:

When you enter an lscheckout –areplicas command at the sibling replica, the comment generated in Step 1 is listed, but the comment generated in Step 4 is not.

When syncreplica –import reports that a packet cannot be imported because it depends on changes not yet received, the message may include one or more lines like the following:

This information may not be correct; the VOB may have more than 0 operations from the specified replica.

When a request for mastership of a branch type fails because requests are denied for one or more instances of the type, the error message says:

This message should say:

If a rebase operation fails with the message No permission to perform operation “remove hyperlink” and you are using a replicated VOB, the baseline hyperlinks associated with your current stream may not be mastered by your current replica. This is because the chmaster –stream command does not change mastership for baseline hyperlinks associated with that stream.

Workaround: Use cleartool describe to find the hyperlinks, and then use chmaster to change their mastership to the appropriate replica. For example:

Rational recommends that you avoid configuring any one host to run the Rational Shipping Server for both ClearCase and ClearQuest, because de-installing either product from such a host will remove the Shipping Server that is used by both products and render the remaining product inoperable. If you must install both ClearCase MultiSite and ClearQuest with the Rational Shipping Server on the same host, ensure that you do the following:

Note: Administrators should be sure that site configuration files for typical host systems do not specify installation of the Rational Shipping Server. Any attempt to install ClearCase on a host where ClearQuest and the Rational Shipping Server is already installed will fail.