1 Status of MultiSite Software Change Requests

This file contains descriptions of noteworthy problems in Version 2002.05.00 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.
-- Known Problems in This Release
-- Problems Fixed in MultiSite Version 2002.05.00

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
-- #CMBU00015700 (#17689) –maxsize option for syncreplica works incorrectly
-- #CMBU00018640 (#20977) import failure during mkhlink operation
-- #CMBU00018695 (#21039) import failure during branch/version creation
-- #CMBU00020860 (#23505) restorereplica oplog entry can be deleted prematurely
-- #CMBU00021382 (#24093) when importing packets in a specific storage class, packets in the default bay are imported also
-- #CMBU00021487 (#24209) replica-creation packet not removed if mkreplica interrupted
-- #CMBU00022378 (#25197) renaming of replica during removal is not recorded in oplog
-- #CMBU00024116 (#27117) import can fail with message: read from input stream failed
-- #CMBU00026057 (#29223) chepoch does not set new replica’s column correctly
-- #CMBU00028738 (#32208) syncreplica —import ignores VOB lock if exception list exists
-- #CMBU00043999 syncreplica does not propagate all directory comments
-- #CMBU00056555 misleading information in syncreplica error message
-- #CMBU00057422 incorrect error message printed when instance denial prevents a request for mastership of a branch type

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

#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:
ms-issues-1.gif
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.

#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.
ms-issues-2.gif
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.
ms-issues-3.gif
3 Replica C sends a synchronization packet to Replica A.
ms-issues-4.gif
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.

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

#CMBU00056555 misleading information in syncreplica error message

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:
Packet requires changes up to epoch-number; VOB has only 0 from replica:replica
This information may not be correct; the VOB may have more than 0 operations from the specified replica.

#CMBU00057422 incorrect error message printed when instance denial prevents a request for mastership of a branch type

When a request for mastership of a branch type fails because requests are denied for one of more instances of the type, the error message says:
Requests are denied for all objects of the given type.
This message should say:
Requests for mastership are denied for one or more instances of the branch type, which prevents requests for mastership of the branch type itself.

Problems Fixed in MultiSite Version 2002.05.00


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
CMBU00017624, CMBU00036852
mkreplica and syncreplica —tape fail on Windows (—tape is no longer supported on Windows)
CMBU00041340
multitool interactive mode caches mastership information (fixed in Release 4.0)
CMBU00052106
MultiSite scripts do not include hosts in alternate_hostnames file
CMBU00052925
mkreplica can fail when used on a VOB containing a trigger type that is the endpoint of a cross-VOB hyperlink
CMBU00053479
gzip hangs VOB server during import phase
CMBU00055000
multitool does not report a failed exit status
CMBU00055596
mkreplica can fail for replicas at schema version 54