Home
Administering
Learn how to administer the product.
Administering HCL VersionVault MultiSite
Learn to configure and manage the HCL VersionVault MultiSite environment to support development activities at different locations.
Replica synchronization
Replica synchronization uses the same export-transport-import procedure that is used during replica creation.
Automated synchronization
You can use scripts and utilities to automate all phases of synchronization.
Transport phase
If sync_export_list or syncreplica puts packets in storage bays (–ship option), you must run shipping_server to process these packets.

Administering
Learn how to administer the product.
- Administering HCL VersionVault
  Learn about performing administrative tasks for an HCL VersionVault community including managing software licenses, user and group accounts, VersionVault server and client hosts, shared data, and the network that connects them.
- Administering platforms for HCL VersionVault
  Learn how to perform HCL VersionVault administrative tasks on supported platforms.
- Administering HCL VersionVault MultiSite
  Learn to configure and manage the HCL VersionVault MultiSite environment to support development activities at different locations.
  - Introduction
    HCL VersionVault MultiSite adds a powerful capability to HCL VersionVault. With MultiSite, developers at different locations can use the same HCL VersionVault versioned object base (VOB). For HCL VersionVault, 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 HCL VersionVaultHCL Compass MultiSite, you need to plan your implementation.
  - MultiSite command set
    This section summarizes the commands for HCL VersionVault MultiSite and HCL VersionVault that display HCL VersionVault MultiSite information. There are a series of MultiSite commands and API functions that display or modify 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 HCL VersionVault. 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.
    - Assumption of successful synchronization
      The export and import phases of synchronization always occur at different times. A sending replica does not require acknowledgment from a sibling replica that a packet has been received and processed successfully. Instead, the sending replica assumes success. This assumption enables an optimization: subsequent updates from a replica do not include the data sent in previous updates.
    - Manual synchronization
      You can manually synchronize replicas by entering explicit syncreplica commands.
    - Automated synchronization
      You can use scripts and utilities to automate all phases of synchronization.
      - Using the HCL VersionVault scheduler
        HCL VersionVault installation adds preconfigured jobs to the scheduler.
      - Export phase
        The scripts sync_export_list creates update packets.
      - Transport phase
        If sync_export_list or syncreplica puts packets in storage bays (–ship option), you must run shipping_server to process these packets.
      - Import phase
        You can automate packet import using receipt handlers and scheduled jobs.
    - Listing synchronization history
      Use the lshistory command or the History Browser list the history of a VOB replica.
    - Synchronizing VOB replicas more efficiently
      You can configure synchronization updates to send only the necessary operations to another replica. Although sending an operation multiple times does no harm, packet creation and transmission is more efficient if you exclude operations that have already been imported at the receiving replica.
  - Administering replicas
  - Using MultiSite for VOB backup and interoperability
    You can use HCL VersionVault 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 an HCL VersionVault 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.

Transport phase

If sync_export_list or syncreplica puts packets in storage bays (–ship option), you must run shipping_server to process these packets.

If you do not use –ship, but want to implement a retry-on-failure capability, you must schedule regular invocations of shipping_server. The shipping server attempts to retransmit any outgoing packets that remain in any of the storage bays because one or more previous attempts have failed.

With the –poll option, sync_export_list invokes shipping_server –poll to process shipping orders located in all storage bays defined in the shipping.conf file (Linux® and the UNIX® system) or in the MultiSite Control Panel (Windows®).

For example, this job invokes shipping_server every day at 04:00 local time:

Job.Begin
       Job.Id: 19
       Job.Name: "Shipping Server Poll"
       Job.Description.Begin:
Every night at 4AM, run the shipping server to send any outstanding orders.
       Job.Description.End:
       Job.Schedule.Daily.Frequency: 1
       Job.Schedule.FirstStartTime: 04:00:00
       Job.DeleteWhenCompleted: FALSE
       Job.Task: 13
       Job.Args: -quiet 1 -poll
Job.End

The following job implements a more aggressive retry-on-failure capability. The shipping server is run every half hour from midnight to 04:00 local time:

Job.Begin
       Job.Id: 20
       Job.Name: "Shipping Server Poll"
       Job.Description.Begin:
Every half hour from midnight to 4AM, run the shipping server to send
any outstanding orders.
       Job.Description.End:
       Job.Schedule.Daily.Frequency: 1
       Job.Schedule.FirstStartTime: 00:00:00
       Job.Schedule.StartTimeRestartFrequency: 00:30:00
       Job.Schedule.LastStartTime: 04:00:00
       Job.DeleteWhenCompleted: FALSE
       Job.Task: 13
       Job.Args: -quiet 1 -poll
Job.End

Have feedback?
Google Analytics is used to store comments and ratings. To provide a comment or rating for a topic, click Accept All Cookies or Allow All in Cookie Preferences in the footer of this page.