Welcome
Administering
Learn how to administer the product.
Administering Rational® ClearQuest® Multisite
Administering Rational® ClearQuest® Multisite
Implementation planning
Before you install and use DevOps Code ClearCase®DevOps ClearQuest® MultiSite, you need to plan your implementation.
MultiSite use model
There are different aspects of your MultiSite use model that affect the implementation and deployment of a MultiSite environment.
Synchronization
The main factors to consider when planning replica synchronization are method, scheduling, and pattern.
Synchronization pattern
The synchronization pattern for a family defines which replicas exchange update packets and the direction of exchange.
Many-to-many synchronization
In the many-to-many synchronization pattern, each replica exchanges packets with all other replicas.

IBM ClearQuest 10.0.9
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 Rational® ClearQuest®
  Learn how to administer the Rational® ClearQuest®.
- Administering Rational® ClearQuest® Web
  This section discusses how to administer Rational® ClearQuest® Web.
- Administering Rational® ClearQuest® Multisite
  Administering Rational® ClearQuest® Multisite
  - Introduction
    and Rational® ClearQuest® MultiSite add a powerful capability to and Rational ClearQuest. With MultiSite, developers at different locations can use the same versioned object base (VOB) or Rational ClearQuest database set (a schema repository and its associated user databases). For Rational ClearQuest, each location has its own copies, or replicas, of the schema repository and user databases. 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.
  - Implementation planning
    Before you install and use DevOps Code ClearCase®DevOps ClearQuest® MultiSite, you need to plan your implementation.
    - MultiSite installation
      MultiSite is installed as an optional product component during the DevOps Code ClearCase®Rational® ClearQuest® installation.
    - MultiSite licensing
      A MultiSite license is required to access an object in a replica by a MultiSite command or GUI, by a DevOps Code ClearCase®Rational® ClearQuest® command or GUI, or by a standard operating system command.
    - Shipping server use with DevOps Code ClearCase® and Rational® ClearQuest®
      If you use both DevOps ClearCase® MultiSite and DevOps ClearQuest® MultiSite, you use the same shipping server for both products. The shipping server is installed when you install DevOps ClearCase MultiSite.
    - Mastership policies
      You need to take mastership policies into consideration when planning your change management processes. Mastership adds another layer of control within your process.
    - MultiSite use model
      There are different aspects of your MultiSite use model that affect the implementation and deployment of a MultiSite environment.
      - Policies for a single code page in a clan
        When you use Rational® ClearQuest®, each client that accesses your Rational ClearQuest databases has its own code page. A code page specifies the set of characters that are valid in a given environment. With Rational ClearQuest, a code page defines the set of characters that are manipulated correctly on a particular client. MultiSite requires that all clients use the same code page.
      - multiutil commands on multiple computers
        By default, only one computer per site is configured to administer schema repositories and user databases and use the multiutil commands.
      - Mastership changes of database objects
        Your plan should state which replicas will master records and other objects. After you create the replicas in the family, you can change mastership of objects.
      - Synchronization
        The main factors to consider when planning replica synchronization are method, scheduling, and pattern.
        Synchronization schedule
        The synchronization schedule for a family defines when replicas in the family send and receive updates. The schedule is affected by many factors, including the rate of development at different sites, the connections among sites, and whether you use MultiSite as a backup strategy.
        Synchronization pattern
        The synchronization pattern for a family defines which replicas exchange update packets and the direction of exchange.
        Directions of exchange
        Synchronization can be unidirectional or bidirectional. In most cases, you will use bidirectional synchronization.
        One-to-one and ring synchronization
        The one-to-one and ring (or round-robin) patterns are simple patterns that are most suitable for small numbers of replicas. As the number of replicas increases, so does the amount of time for changes originating at one replica to be received at a replica at the other side of the ring.
        One-to-many synchronization
        The one-to-many pattern involves one replica, or root site sending packets to all other replicas in the family.
        Many-to-many synchronization
        In the many-to-many synchronization pattern, each replica exchanges packets with all other replicas.
      - Backup strategy for databases
        Perform regular backups of your vendor databases at all sites. If the database server machine crashes or you lose the database storage area, you can restore the database from the backup copy and use the replica restoration procedure to replace any missing operations.
      - Scrubbing parameters for replicas
        When a command makes a change to a replica, an entry is recorded in the replica’s operation log. Also, when you export an update packet, an export_sync record is created for each target replica. These records are used by the recoverpacket command to reset a replica’s epoch number matrix.
      - Path names that contain spaces
        On computers running Windows™, if the path name of a receipt handler or a shipping order contains spaces, DOS short name resolution must be enabled for the file system on which the receipt handler or shipping order is located. This property is enabled by default. If this property is not enabled, the shipping server cannot invoke the receipt handler or process the shipping order.
    - UCM integration compatibility issues
      If you use the UCM integration of DevOps Code ClearCase® and Rational® ClearQuest®, there are some compatibility issues that must be considered when administering MultiSite.
    - Overview of deployment tasks
      Before deploying MultiSite, test your plan and perform a test run to ensure that your synchronization and defect-tracking process are effective.
    - Responsibilities of MultiSite administrators
      The MultiSite administrator must perform the tasks described in this topic.
  - 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.
  - Database replica creation
    Creating your database replicas requires careful planning and consideration part of which involves making decisions about mastership and methods of packet delivery.
  - Replica synchronization
    Replica synchronization uses the same export-transport-import procedure that is used during replica creation.
  - Database replicas administration
    Sustaining a smoothly functioning MultiSite environment requires dedicated administration. Many administrative processes can drastically change your environment and require careful consideration and planning.
  - Mastership management
    The management of mastership affects how database objects are accessed and manipulated by users in your MultiSite environment. Mastership management is an ongoing process as new objects are entered into the database and users' requirements change.
  - Troubleshoot MultiSite operations
    There are common situations in which running a Rational® ClearQuest® MultiSite command produces an unexpected result, sometimes accompanied by a warning or error message.
  - MultiSite command set
    This section summarizes the commands for DevOps ClearCase® MultiSite and DevOps ClearCase that display DevOps Code ClearCase MultiSite information. There are a series of MultiSite commands and API functions that display or modify MultiSite information.
Reporting
Learn how to generate reports for the product.
Developing
Learn how to develop schemas by using the Rational® ClearQuest® Designer.
Managing change and releases
Learn how to manage change and release in the product.
Integrating
You can integrate Rational® ClearQuest® with other software by adding packages to existing schema.
Extending product function
Learn how to extend the product.
Reference
Review reference information for the product.
Tutorials

Many-to-many synchronization

In the many-to-many synchronization pattern, each replica exchanges packets with all other replicas.

Figure 1. Many-to-many synchronization pattern

Advantages:

For companies with few sites, this pattern keeps each replica’s epoch table the most accurate for all siblings.
If one site is unavailable, the other sites do not have to change their patterns to continue synchronizing.

Disadvantages:

Each administrator must maintain more synchronization jobs and spend more time keeping, creating, tracking, and importing packets.
Fully synchronizing the family requires n*(n-1) packets and connections, where n represents the number of replicas in the family. For example, if there are four siblings displayed in Figure 1, a total of 12 connections are required for synchronization. Similarly, a family of five siblings would require 20 packets and connections, while a family of six siblings would require 30 packets and connections, and so on. Transferring all these packets around can be inefficient and expensive.