Status of MultiSite Software Change Requests

This file contains descriptions of noteworthy problems in Release 4.2 of Rational ClearCase MultiSite.

Note: The ClearCase Product Family development group has switched to a new change request system since ClearCase 4.0 was released. ID numbers differ between these two systems. This document lists both numbers. The new number appears first and includes a CMBU prefix. The former five-digit number appears in parentheses.

1.1 Known Problems in This Release

The following are the known problems in this release of MultiSite.

#CMBU00013462 (#15179) no explanation for non-applicable packet by syncreplica

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.

#CMBU00015700 (#17689) -maxsize option for syncreplica works incorrectly

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.

#CMBU00017624, CMBU00036852 (#19829, #17515) mkreplica and syncreplica -tape fails on Windows

When you execute mkreplica -tape or syncreplica -tape on Windows, it may fail with the error message:

Unable to write file "\\.\tape0":no such file or directory

Workaround: Use disk files to hold packets, and transfer the packets to and from tape manually.

#CMBU00018640 (#20977) import failure during mkhlink operation

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.

#CMBU00018695 (#21039) import failure during branch/version creation

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.

#CMBU00020860 (#23505) restorereplica oplog entry can be deleted prematurely

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 -completed 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.

#CMBU00021382 (#24093) when importing packets in a specific storage class, packets in the default bay are imported also

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.

#CMBU00021487 (#24209) replica-creation packet not removed if mkreplica interrupted

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.

#CMBU00022378 (#25197) renaming of replica during removal is not recorded in oplog

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.

#CMBU00024116 (#27117) import can fail with message: read from input stream failed

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.

#CMBU00026057 (#29223) chepoch does not set new replica's column correctly

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:

1.
Replica A and Replica B synchronize weekly.

2.
At Replica A, the administrator enters a mkreplica -export command to create Replica C and sends the packet to the new site, where the administrator imports the replica-creation packet. Development starts at Replica C.

3.
Replica C sends a synchronization packet to Replica A.

4.
Replica A sends its weekly synchronization packet to Replica B. This packet contains the mkreplica operation that created Replica C, along with work done at Replica C. The packet is lost before it gets to Replica B.
5.
The administrator at Replica B enters an lsepoch command and sends the output to the administrator at Replica A. However, because Replica B does not know about Replica C, Replica B's epoch table does not have information about Replica C, and neither does the lsepoch output:
multitool lsepoch B@/vobs/dev
Oplog IDs for row "B" (@ boston):
          A=586
          B=985
6.
The administrator at Replica A uses the lsepoch output in a chepoch command:
multitool chepoch -force B A=586 B=985
Epoch row successfully set.

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.

#CMBU00028738 (#32208) syncreplica -import ignores VOB lock if exception list exists

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

#CMBU00041340 multitool interactive mode caches mastership information

If a mastership change is made in another multitool process while you are in multitool interactive mode, you must exit and reenter interactive mode in order to see the change.

#CMBU00043999 syncreplica does not propagate all directory comments

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

1.
Check out a directory and add a new element.

The checkout event record includes a comment of the form "Added file element "filename"."

2.
Leave the directory checked out.
3.
Send an update packet from the current replica to a sibling replica.
4.
Add another element to the directory.

A comment for this element is appended to the event record.

5.
Send an update packet from the current replica to a sibling replica.

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

1.2 Problems Fixed in MultiSite Release 4.2

Table 1 lists significant problems in previous MultiSite releases that are fixed in this release.

Table 1 MultiSite Problems Fixed in This Release

Problem Number

Description

CMBU00044396

files in /tmp are not deleted when a synchronization import fails

CMBU00044522

symbolic link protection can be changed incompatibly

CMBU00045247

mkreplica -import -stgloc can select non-local storage locations

CMBU00045935

mkreplica -import -stgloc fails

CMBU00046040

chepoch -actual fails and creates a core file when it cannot connect to the server for the sibling replica

CMBU00046151

sync_receive doesn't recognize replica name containing a hyphen

CMBU00046195

chmaster -all -force can change properties of checked-out versions

CMBU00046719

chreplica can change ownership-preservation property incorrectly

CMBU00047123

lsepoch -actual on a Release 4.1 host can fail if replica is on a Release 4.0 host and the 4.1 host cannot resolve the hostname of the 4.0 host

CMBU00048100

oplog information sent to STDOUT instead of STDERR when a synchronization import fails


Copyright © 2001 by Rational Software Corporation. All rights reserved.