Welcome
Administering
Learn how to administer the product.
Administering DevOps Code ClearCase® MultiSite
Learn to configure and manage the DevOps Code ClearCase® MultiSite and Rational® ClearQuest® MultiSite environments to support development activities at different locations.
Troubleshooting MultiSite operations
When you encounter a situation where running a DevOps Code ClearCase® MultiSite command produces an unexpected result, or produces a warning or error message, the information in this section can assist you in troubleshooting the problem.
Synchronization import problems
This section describes problems that can occur during the import phase of synchronization.
Recovering from lost packets
There are several circumstances in which a replica-creation or update packet is generated but is never applied at one or more of its destinations.
Lost update packet
If you have lost an update packet, the state of the replica being updated might not be accurate. You should reset the epoch row in the replica being updated and run the synchronization export from the updating replica again.
Method 2: lsepoch and chepoch method
To recover a lost packet, you can use the lsepoch command to determine the receiving replica's epoch number matrix and then use a chepoch command to reset the sending replica's epoch table.

Overview
Learn general information about the product.
Installing
Learn how to install the product.
Upgrading and migrating
Learn how to upgrade and migrate data for the product.
Administering
Learn how to administer the product.
- Administering DevOps Code ClearCase®
  Learn about performing administrative tasks for a DevOps Code ClearCase® community including managing software licenses, user and group accounts, ClearCase server and client hosts, shared data, and the network that connects them.
- Administering platforms for DevOps Code ClearCase®
  Learn how to perform DevOps Code ClearCase® administrative tasks on supported platforms.
- Administering DevOps Code ClearCase® MultiSite
  Learn to configure and manage the DevOps Code ClearCase® MultiSite and Rational® ClearQuest® MultiSite environments to support development activities at different locations.
  - Introduction
    DevOps Code ClearCase® MultiSite and add a powerful capability to DevOps Code ClearCase and . With MultiSite, developers at different locations can use the same DevOps Code ClearCase versioned object base (VOB) or . For DevOps Code ClearCase, each location (site) has its own copy (replica) of the VOB. At any time, changes made in one replica can be sent in update packets to other replicas. You can manage replicas by using the command-line tools.
  - MultiSite operation
  - Implementation planning
    Before you install and use DevOps Code ClearCase® MultiSite, you need to plan your implementation.
  - MultiSite command set
    This section summarizes the commands for DevOps ClearCase® MultiSite and DevOps ClearCase that display DevOps Code ClearCase MultiSite information.
  - Packet transportation methods and configuration
    The method you choose for transporting packets between replicas depends on connectivity. If your replicas do not have IP connectivity, you must use a file-based transport method. If your replicas have connectivity, you can use the store-and-forward facility.
  - Feature levels
    Feature levels allow different replica hosts in a VOB family to run different versions of DevOps Code ClearCase®. You can raise the feature level of either a single replica host or an entire VOB family.
  - Creating VOB replicas
    Before creating a replica, you must make decisions about branching, mastership, identities and permissions preservation, and method of packet delivery.
  - Replica synchronization
    Replica synchronization uses the same export-transport-import procedure that is used during replica creation.
  - Administering replicas
  - Using MultiSite for VOB backup and interoperability
    You can use DevOps Code ClearCase® MultiSite to back up a VOB and to provide access to VOBs in a heterogeneous network.
  - Troubleshooting MultiSite operations
    When you encounter a situation where running a DevOps Code ClearCase® MultiSite command produces an unexpected result, or produces a warning or error message, the information in this section can assist you in troubleshooting the problem.
    - General MultiSite troubleshooting tips
      Many problems can be clarified, if not solved, by examining the various log files, checking your system configuration, and listing the history of exports.
    - Replica export problems
      Common mkreplica –export problems include specifying a new replica name that matches one that already exists or having an old package left over from a previous failed run.
    - Replica import problems
      Common problems encountered while attempting to import an update packet include permissions issues, naming conflicts in the object or tag registry.
    - Synchronization export problems
      Problems encountered while during the export phase of synchronization typically are the result of not being able to find the appropriate oplog entry.
    - Transport problems
      This section describes problems that can occur during the transport phase of synchronization.
    - Synchronization import problems
      This section describes problems that can occur during the import phase of synchronization.
      - Packets accumulate in incoming storage bay
        A recoverable error occurs when an update packet is lost and therefore is not applied to your replica.
      - Packet is not applicable to any local replicas
        A synchronization import can fail when a replica has been moved and the host-name property has not been updated with the chreplica command.
      - Read from input stream fails
        If a packet is corrupted, a syncreplica –import command can fail with an error message about the "read from the input stream" failing.
      - Element changes during operation
        If a syncreplica –import command fails with an error message about the element changing during the operation, try the import operation again.
      - The rmreplica operation cannot be imported
        Import of an rmreplica operation fails if the importing replica records that the removed replica still masters objects.
      - Pre 7.0 systems only: database limit is exceeded
        DevOps Code ClearCase® versions 4.0 and later include support for VOB database schema (version 54). If you update one or more replicated VOBs in a family to schema version 54, you do not have to update the other replicas in the VOB family immediately. However, you must update all replicas before one of the updated replicas exceeds the database limit of the previous schema (version 53). If you do not, replicas that have not been updated cannot import synchronization update packets from the updated replica.
      - Replica incarnation is old
        Differences in the replica incarnation can prevent syncreplica –import command at the importing replica from completing its operation properly.
      - Warning on receipt of packet from earlier MultiSite version
        Different versions of MultiSite have different packet protocols. When multitool with a newer protocol reads a packet with the older protocol, it prints a warning message.
      - Miscellaneous problems
        There are simple problems (disk space, locked replicas, licensing, multiple processes running) that can cause a packet import to fail.
      - Recovering from lost packets
        There are several circumstances in which a replica-creation or update packet is generated but is never applied at one or more of its destinations.
        Lost replica-creation packet
        If you discover that there is a lost replica-creation packet, you can rename the new replica and then rerun the original mkreplica command.
        Lost update packet
        If you have lost an update packet, the state of the replica being updated might not be accurate. You should reset the epoch row in the replica being updated and run the synchronization export from the updating replica again.
        Method 1: Connected method
        You can use sync_export_list –update or chepoch –actual to set the epoch row to match the actual state of the receiving replica.
        Method 2: lsepoch and chepoch method
        To recover a lost packet, you can use the lsepoch command to determine the receiving replica's epoch number matrix and then use a chepoch command to reset the sending replica's epoch table.
        Method 3: lshistory and chepoch method
        To recover a lost packet, you can use the lshistory command to determine the epoch numbers when the packet was generated and then use a chepoch command to reset the sending replica's epoch table.
        Method 4: lshistory and recoverpacket method
        To recover a lost packet, you can use the lshistory command to determine the time of the last successful import and then use a recoverpacket command to recover all packets since that time.
      - Inconsistent changes to replica
        A recoverable error occurs if syncreplica –import detects that an incoming change is inconsistent with another change that has already been applied to the replica.
      - Automatic renaming of type objects and replica objects
        The syncreplica –import command resolves naming conflicts among type objects or replica objects created at two or more replicas.
    - Running epoch_watchdog
      The epoch_watchdog script checks whether a replica’s epoch numbers have rolled back without a restorereplica command being run.
    - Restoring and replacing VOB replicas
      Occasionally, a VOB storage directory is lost. This can occur because of a hardware failure (for example, disk crash), a software failure (for example, operating system-level file system corruption), or a human error (for example, an rm –fr or del command). If an unreplicated VOB storage directory is lost, you can restore a recent copy from backup and resume development work. The changes made between the time of the backup and the time of the failure are not recoverable.
    - Restoring replica storage that has been accidentally deleted
      This is the process to follow when a replica's storage directory is lost, and there is no backup to be restored.
Developing
Learn how to develop software with DevOps Code ClearCase® and ClearCase Remote Client.
Managing change and releases
Learn how to manage change and release in the product.
Integrating
Learn how to integrate DevOps Code ClearCase® with other products.
Tutorials
Complete tutorials with specific learning objectives for the product.
Extending product function
Learn how to extend the product.
Reference
Review reference information for the product.
Glossary

Method 2: lsepoch and chepoch method

To recover a lost packet, you can use the lsepoch command to determine the receiving replica's epoch number matrix and then use a chepoch command to reset the sending replica's epoch table.

About this task

Procedure

At the receiving replica, use the lsepoch command to display the replica’s epoch number matrix:


multitool lsepoch sanfran_hub@/vobs/dev
For VOB replica "/vobs/dev":
Oplog IDs for row "sanfran_hub" (@ goldengate):
 oid:7ag3b0bc.defa11d0.ba57.00:01:72:73:3c:94=950     (bangalore)
 oid:87f6265f.72d911d4.a5cd.00:01:80:c0:4b:e7=1300    (boston_hub)
 oid:0eaa6fc3.737d11d4.adbe.00:01:80:c0:4b:e7=2000    (sanfran_hub)

Use this output in a chepoch command at the sending replica:

multitool chepoch sanfran_hub bangalore=950 boston_hub=1300 sanfran_hub=2000
Change oplog IDs in row "sanfran_hub" [no] yes
Epoch row successfully set.