Resets epoch number matrix so that changes in lost packets are resent
recoverpacket [ –c·omment comment | –cfi·le comment-file-pname | –cq·uery
| –cqe·ach | –nc·omment ] [ –sin·ce date-time ] replica-selector ...
The recoverpacket command resets the epoch row at a sending replica to reflect the last synchronization sent to a replica before a particular time. It scans through a list of epoch rows saved at the time of each export, looking for an entry prior to the time specified. When it finds an entry, it uses the associated row to reset the epoch row for the specified receiving replica. The next packet that is exported includes the changes that were in the lost packet.
When you send an update packet to another replica, success of the transport and import phases is assumed. Therefore, the sending replica’s epoch number matrix is updated to reflect that the changes are made at the receiving replica. However, if the packet is lost before reaching the receiving replica, the sending replica’s assumption that the receiving replica is up to date is incorrect.
The epoch numbers at the sending replica must be returned to the values they had before the packet was sent. Making these corrections to the sending replica’s epoch number matrix causes it to include the same changes in the next update packet it sends to the receiving replica.
The administrator at the receiving replica must run an lshistory command to determine the time of the last successful import. The administrator at the sending replica uses this time in the recoverpacket command.
Note: If the two replicas are not in the same time zone or you do not send packets at the same time you generate them (for example, you generate packets at midnight and send them at 6:00 A.M.), you must adjust for the time difference.
If there are no saved epoch rows that are as old as the specified time, the recoverpacket command fails. In this case, the administrator at the receiving replica must use the lsepoch command to determine the correct epoch number, and the administrator at the sending replica must run chepoch on the sending replica to reset the epoch row. See the chepoch reference page and Lost Update Packet.
Identities: You must have one of the following identities:
Locks: An error occurs if one or more of these objects are locked: VOB.
Mastership: No mastership restrictions.
Default
Creates one or more event records, with commenting controlled by the standard ClearCase user profile (default: –nc). See Event Records and Comments in the multitool reference page. To edit a comment, use cleartool chevent.
–c·omment comment | –cfi·le comment-file-pname | –cq·uery | –cqe·ach | –nc·omment
Overrides the default with the specified comment option.
Default
If the time is not specified, recoverpacket uses the current time (and, therefore, resets the epoch row so that the changes in the most recent update packet are resent).
–sin·ce date-time
Specifies the time of the last successful processing of a packet at the receiving replica. The date-time argument can have any of the following formats:
date.time | date | time | now
where:
Specify the time in 24-hour format, relative to the local time zone. If you omit the time, the default value is 00:00:00. If you omit the date, the default value is today. If you omit the century, year, or a specific date, the most recent one is used. Specify UTC if you want the time to be resolved to the same moment in time regardless of time zone. Use the plus (+) or minus (-) operator to specify a positive or negative offset to the UTC time. If you specify UTC without hour or minute offsets, the default setting is Greenwich Mean Time (GMT). (Dates before January 1, 1970 Universal Coordinated Time (UTC) are invalid.)
Examples:
22-November-2002
sunday
yesterday.16:00
8-jun
13:00
today
9-Aug.10:00UTC
Default
You must specify a replica. If you do not specify a vob-selector, the command uses the current VOB.
replica-selector
Updates the current replica’s estimate of the state of replica-selector. Specify replica-selector in the form [replica:]replica-name[@vob-selector]
multitool recoverpacket –nc –since Monday sanfran_hub Using epoch information from Monday 10/21/02 00:00:00 Epoch row for replica "sanfran_hub" successfully reset.
multitool recoverpacket –c "send latest packet" boston_hub@\dev Using epoch information from Thursday 10/24/02 14:55:34 Epoch row for replica "boston_hub" successfully reset.
At replica bangalore:
cleartool lshistory replica:bangalore@\dev 19-Oct.15:36 smg import sync from replica "boston_hub" to replica "bangalore" "Imported synchronization information from replica "boston_hub". ...
At replica boston_hub (remember to adjust for the time zone difference):
multitool recoverpacket –since 19-Oct.05:06 bangalore@/vobs/dev Using epoch information from Saturday 10/19/02 05:05:45 Epoch row for replica "bangalore" successfully reset.
multitool syncreplica –export –fship bangalore@/vobs/dev Generating synchronization packet /opt/rational/clearcase/shipping/ms_ship/outgoing/sync_boston_hub_2 2-Oct-02.15.44.28_4896_1 - shipping order file is /opt/rational/clearcase/shipping/ms_ship/outgoing/sh_o_sync_boston_ hub_22-Oct-02.15.44.28_4896_1 Attempting to forward/deliver generated packets... -- Forwarded/delivered packet /opt/rational/clearcase/shipping/ms_ship/outgoing/sync_boston_hub_2 2-Oct-02.15.44.28_4896_1
chepoch, lsepoch, restorereplica
The Operation Log