Eric J Ostrander's

ClearCase / ClearQuest / Git/Stash "how to" pages.

ClearCase MultiSite, how do I ...
Misc   |   Ownership & Mastership   |   Packets & Orders   |   Replicas

This page is my own personal work. Anyone can use it for their own edification, but must realize that this material is not supported by me and the site is not affiliated with IBM Rational Software or Atlassian.
Misc.
Back to the TOP
Convert to the new 4.x CCMS scripts and CC Scheduler.
Set up an alternate storage/shipping class.
Restore a replica from backp. (restorereplica)
Handle type naming conflicts.
Set up CCMS on a firewall.
Set up exceptional-circumstance email notification.
Ensure epoch numbers are not rolled back without restorereplica. (epoch_watchdog)
List available VOBs by their family UUID.
The multitool command.
Replicate triggers.
Share the shipping server between CC and CQ.
Determine if CCMS is installed on a particular machine.
Rename or remove a shipping class.
Ownership & Mastership
Back to the TOP
Change the mastership of a CC object. (chmaster)
Change whether a replica is ownership-preserving. (chreplica)
Request/enable a change in branch mastership. (CC 4.x)(reqmaster)
List masterships. (lsmaster)
Share MetaData types.
Find all elements mastered by a site.
Determine the mastership of an object.
Packets & Orders
Back to the TOP
Retransmit a missing packet. (recoverpacket,chepoch)
List any packets that might be in the shipping bay. (lspacket)
Manually sync replicas. (syncreplica)
Manually create a shipping order. (mkorder)
Transmit packets generated with -ship. (shipping_server)
Set up an alternate storage class.
List epoch information. (lsepoch)
Create a custom packet. (mkorder)
Determine the contents of a sync packet. (lspacket)
Compress synchronization packets.
Replicas
Back to the TOP
Create an initial replica. (mkreplica)
Remove/retire a replica. (rmreplica)
Manually sync replicas. (syncreplica)
Change the hostname associated with a replica. (chreplica)
Replica/element ownership/permissions. (chreplica)
Determine the replica name of a VOB. (lsreplica,describe)
Move a replica. (chreplica)
Rename a replica. (rename)
List VOB replicas. (lsreplica)
List a replica's properties. (describe)
Indicate whether a sibling replica has IP connectivity. (chreplica)
Determine the incarnation number of the replica. (dump)
Find out about unfiltered replica types.
List all replicated VOBs in a CC region.
Switch a replica to managed mode.
Run syncreplica from a remote host.
Get details about oplog events. (dumpoplog)
Get a replica's history. (lshistory replica:name@vobtag)
Convert to the new 4.x CCMS scripts and CC Scheduler.
CC comes with its own Job Scheduler as of 4.0. Automatic syncreplicas do not need to rely on the native UNIX crontab or Windows at. Also, the RECEIPT-HANDLER scripts have been updated as well. The following procedure details the steps necessary to migrate from the old method to the new.
NOTE: The migration is not mandatory. The old scripts, if saved across the upgrade, will still work along with standard crontab/at entries.
1) Ensure you have permission to run the Scheduler. See the schedule command for details.
2) Determine all import & export jobs and receipt handlers. On UNIX, import/export syncreplicas are run from root's or the VOB Administrator's crontab and the receipt handlers are in /var/adm/atria/config/shipping.conf. On Windows, use the CCMS Control Panel applet. These jobs and scripts are the ones that are going to be converted.
3) Determine the new scripts and options to use. Read the sync_export_list and sync_receive reference pages for details.
Old Script New Script
sync_sendall.sh sunc_export_list -all -quiet 1
sync_sendall.sh sync_export_list -quiet 1 -replicas replica-name@vob-tag
sync_receive.sh,logit.sh sync_receive -quiet 1
sync_recpt.sh sync_receive -quiet 1
4) Scheduler: If you need to still use the scripts in ccase-home-dir/config/cron (on UNIX and Windows), copy those files to /var/adm/atria/scheduler/tasks on UNIX and ccase-home-dir\var\scheduler\tasks on Windows. Define tasks for those scripts (except receipt handlers) by editing the/var/adm/atria/scheduler/tasks/task_registry on UNIX and ccase-home-dir\var\scheduler\tasks\task_registry on Windows. Add the new task at the end of the file. The Task.Id must be unique. The following is an example of the task implementation for a local script called sync_export_lex.pl. 
Task.Begin
	Task.Id:	110
	Task.Name:	"Sync Export Lexington"
	Task.PathName:	sync_export_lex.pl
Task.End
5) Update the shipping.conf file to point to the new path, namely the tasks subdirectory.
6) Remove crontab/at entries for export/import jobs.
7) Schedule synchronization jobs: 
  # ct schedule -edit -schedule command
The definitions can be the standard CCMS Sync Export and Import tasks or ones defined above in step (4). Save and close the file.

Back to the INDEX.
Set up an alternate storage class.
The store-and-forward facility can be configured to separately handle packets destined for different VOBs. That is, storage bays can be different for different VOBs. This is useful if one is concerned about security between VOBs. Classes can also be used if one sends non-CC packets using CCMS to a specific location on the machine not necessarily a shipping bay. To create a new class, see ccase-home-dir/config/services/shipping.conf on UNIX and the CCMS Control Panel on Windows. The following lines are for Unix. The default shipping.conf is stored in shipping.conf.template. For Windows, they are all entered directly under the Add Class or Modify Class buttons.

1) Designate alternate shipping bays. Specify the directory in which incoming and outgoing packets are to be stored for the designated class. Any packet without a designated class uses "-default". Remember to create directories called "incoming" and "outgiong" under the directories listed below. 
STORAGE-BAY  class-name      storage-directory
RETURN-BAY   class-name      return-directory
2) Set the class expiration time. Set the number of days after which a packet will expire. That is, place the wayward packet in the return bay if hasn't been successfully delivered to its destination within the designated number of days. The default is 14. 
EXPIRATION  class-name  days
3) Specify a receipt handler. When a packet arrives, CCMS needs to know how it should handle it. Use the default sync_recpt.sh receipt handler as an example or simply use it. If no receipt handler is specified, the system will automatically use the default. 
RECEIPT-HANDLER  class-name  /path/script
Back to the INDEX.
Restore a replica from backup.

NOTE: The restorereplica subcommand must be run IMMEDIATELY after restoring a VOB to ensure the VOB's integrity with respect to other VOBs in its family.

The restorereplica subcommand changes the local replica so that syncreplica will generate a special update request. It locks the local replica and marks it as being in the process of restoration. It does a "lsreplica -long" to indicate which replicas must send restoration updates. It will inform you when all updates have been rcvd and applied. At that time, unlock the VOB. Must be the VOB owner, root (UNIX) or in the clearcase group (Windows). 
  # mt restorereplica
  # mt syncreplica -export -fship replica-selector(s)

Remote sites have to import and export their own syncreplica commands.
Once each remote site has sync'ed back with the local site:

  # mt syncreplica -import -receive     (needed only if automatic RECEIPT-HANDLER not used)
  # ct unlock vob:vob-tag               (only after all sites processed)
Some options:
-f.orce Suppresses the confirmation.
-invob   vob-tag Specify a VOB other than the current one.
NOTE: By default, the restorereplica command requires answers from all replicas in the family before it can be declared restored. However, it may be sufficient that only a sync with the replica with which the local replica last sync'ed is necessary. That is, the replica with which the local replica last sync'ed should contain all the changes the local replica knew about just prior to its backup. Use the restorereplica -override option (formerly -completed) to prematurely complete the process so that you can unlock the VOB. WARNING, incorrect application of this option can lead to irreparable damage to your VOB family. Consult the CCMS Manual and/or call Rational tech support before using it.

Back to the INDEX.
Handle type naming conflicts.
Because types can be created at sites remote from each other, the possibility exists that two types get named the same. To avoid this, it is highly recommended that the CC admins agree on a naming convention ahead of time. Most projects choose to encode the name (or portion thereof) of their sites in the type names. For example, if Chandler and Denver are MultiSiting, branches created in Chandler would be ch_branch and those created in Denver would be dn_branch. Except for branch and label conflicts, different kinds of types can be named the same. For example, you can have a hyperlink named "dev" and a branch named "dev" without a conflict.
If two types have the same name at remote sites, the import will detect the conflict and output a message to the effect "multitool: Warning: To avoid name conflict, generated name "replica-name:type-name" for metadata-type type object". In this case, one can simply leave the names alone and live with it or either site can rename their type. However, if the importing site renames theirs, the other type will still be known as replica-name:type-name in the local VOB. So, the best thing to do is have the remote site rename theirs and send an update packet. The type in the local VOB will be automatically renamed from replica-name:type-name to type-name.
NOTE: Users cannot generate metadata types with imbedded colons. However, those generated by CCMS as a result of naming conficts can be referenced via config_specs and the find command to use and/or rename them.

Back to the INDEX.
Set up CCMS on a firewall.
There are a few methods for getting CCMS data through a firewall.
1) email: This method requires the CC administrator to write scripts to send and receive email containing packets. In general, one would create the packet via mkorder, compress the packet (gzip, zip or compress), uuencode it and then mail it to the remote machine with a special subject line. The mail tool at the remote site would then need to act on the attachment and reverse the above process. There isn't anything special needed on the firewall itself, as it is most likely already set up for handling email. When creating the packets, one should consider using the -maxsize option so as to not overload email. Email is ubiquitous and requires no interaction with a system administrator. However, email is less efficient and prone to losses more than a direct connect using ftp or TCP/IP.
2) ftp: With this method as well, one needs to write customized scripts to handle the traffic. Nothing needs to be installed on the firewall itself, as it most likely already handles ftp traffic. Ftp is common, well understood and more efficient than email. On the other hand, the scripts to handle the traffic can be more complicated. As with the email method, no system administrator involvement is required.
3) store-and-forward: This method uses the CCMS store-and-forward utility, which needs to be installed on the firewall. When installing it there, don't install any other CC utility, just the CCMS store-and-forward. By default, CCMS will use any open port. To specify a range of ports to use, set min and max port number environment variables. On a UNIX firewell, edit <clearcase-home-dir>/etc/atria_start. Add the following lines somewhere before the albd daemon gets started: 
#
# Set values for minimum and maximum port numbers.
#
CLEARCASE_MIN_PORT=min-port
CLEARCASE_MAX_PORT=max-port
On a Windows firewall, set them as system environment variables. One should allow a range of at least 4 ports, as the shipping_server will fork if more than one packet is being processed. However, it isn't necessary to specify more than 10, as that is the limit of shipping_server. Remember to set the routing appropriately for all sites. That is, each site needs to send packets to the firewall directly and not the machine on which the remote replica lives. Also, set the routing on the firewall itself. On UNIX, set these in the /var/adm/atria/config/shipping.conf file. On Windows, set them in the CCMS Control Panel.

Back to the INDEX.
Set up exceptional-circumstance email notification.
The indicated user is notified about any exceptional circumstances that arise in the operation of the store-and-forward mechanism (for additional detail, see the comments for the NOTIFICATION-PROGRAM keyword). For exceptions that arise from the processing of a specific shipping order, a notification is also sent to any additional administrators specified in the shipping order itself.
On UNIX, see ADMINISTRATOR in /var/adm/atria/config/shipping.conf. To enable email notification on Rational Shipping Server machines where CC is not installed, ask Rational Support for Technote #22590.
On Windows, see "Administrator Email" in the CCMS control panel.
If additional users need to be listed, on UNIX in the conf file, place each on a separate line starting with word ADMINISTRATOR, and on Windows it is comma-separated list.

Back to the INDEX.
Ensure epoch numbers are not rolled back without restorereplica.
New in CC 5.0, a scheduled job can be run that records in a logfile the epoch numbers of VOB replicas. The script (epoch_watchdog) lives in config/scheduler/tasks in cc-home on Windows and /usr/atria on UNIX. The epoch_logs permanent log is stored in cc-home\var\log on Windows and /var/adm/atria/log on UNIX.
For example, if a replica has generated 700 oplog entries, crashes, and is then restored, but only up to oplog 600, and entries 601-700 had been already sent to another site, the restored replica will start generating oplog entries at 601 again causing import problems at the other site. In a normal restore, restorereplica should be run to recover entries 601-700 from the remote site. If restorereplica is not run, there could be serious problems.
The scheduled job should run frequently during the day to ensure oplog entries in a replica's database are up to those recorded in the hard log. The job is not scheduled automatically when CCMS is in use. It must be scheduled by an administrator. See "Running epoch_watchdog" in the Rational ClearCase MultiSite Administrator's Guide.

Back to the INDEX.
The multitool command.
The multitool command is used in conjunction with a subcommand, such lsreplica to manager a CCMS environment from the CLI. It can be used in an interactive or non-interactive mode. It is very often aliased as "mt". 
Interactive:
  # mt lsepoch
  ...
Non-interactive:
  # mt
  multitool> lsepoch
  ...
  multitool> quit
  #
Options:
-e Multitool exits non-interactive mode automatically if an error occurs.
-ver Disply the version of multitool and any of its patches.
-VerAll In addition to displaying the version, display the version of all libraries used.
-status New in CC 2002/5.0, while in non-interactive mode, a 1 or 0 is returned for each subcommand executed.

Back to the INDEX.
Replicate triggers.
When a VOB is replicated, its triggers are not. Taking advantage of shipping classes and receipt handlers we can have triggers automatically synchronized along with other CC data. The following procedure was written for a Windows environment, but is effectively the same for both UNIX and Windows. A noteable difference is that Windows uses a MultiSite Control Panel applet and UNIX uses a shipping.conf file.
1) At all sites, create a directory called "\\machine\share\triggers" that will hold any trigger scripts. You can use a different name, such as "bin", as long as it's consistent across all sites and the receipt handler script and shipping class use the same UNC path. The machine and share referenced in the UNC path are the CCMS server at the remote site.
2) In that directory create the following directories:
ms_ship\incoming
ms_ship\outgoing
ms_rtn\incoming
ms_rtn\outgoing
3) At all sites, register the triggers directory. The command would be like "ct mkstgloc -vob triggers \\machine\share\triggers".
4) In the triggers directory, create a trigger script that will package up and send off any new trigger that is created. The trigger types that will use this trigger script, since they're the first, will need to be created manually in a VOB at the local site.
5) In the local VOB that will be used to create the original definitions of new triggers, create the following trigger types: 
  # ct mktrtype -type -c "Replicate new triggers to other sites." -postop mktype -trtype -all -exec "ccperl \\machine\share\triggers\trigger_replication.pl" remote_trigger_creator
  # ct mktrtype -type -c "Remove triggers from other sites."      -postop rmtype -trtype -all -exec "ccperl \\machine\share\triggers\trigger_replication.pl" remote_trigger_remover
  # ct mktrtype -type -c "Rename triggers at other sites."        -postop rename -trtype -all -exec "ccperl \\machine\share\triggers\trigger_replication.pl" remote_trigger_renamer
6) In the triggers directory, create a receipt handler called "trigger_receipt_handler.bat".
7) At all other sites, in the MultiSite Control Panel applet, create a new shipping class (Add Class). Make the Storage Class name "triggers". Set the Storage Bay Path to point to the triggers\ms_ship directory. It would be something like \\machine\share\triggers\ms_ship. Set the Return Bay Path to something like \\machine\share\triggers\ms_rtn. Set the Receipt Handler Path to something like \\machine\share\triggers\trigger_receipt_handler.bat. Click OK to save the new shipping class.
When a trigger is created, removed, or renamed in the local VOB, the trigger definitions above will invoke the trigger_replication script. That script should create two files to be sent out. One is the definition of the operation just performed on a trigger type, and the second one, needed only for new triggers, is the actual trigger script itself. When those packets are sent out, be sure to send them to the "triggers" shipping class. At the other sites the receipt handler will execute the command (trigger type definition). This kind of automation is much easier if all sites use identical VOB tags.
However, this system has some short-comings. For example, if a trigger type is removed, the actual trigger scripts won't be removed from the remote site's triggers directory; a minor inconvenience. Also, if you rename a trigger script that is associated with an existing trigger, delete the old trigger type and create a new one instead of using the -replace option; that way the new script with its new name will be transferred to the other sites. So, this is only a basic workaround.

Back to the INDEX.
Share the shipping server between CC and CQ.
Rational recommends that you avoid configuring any one host to run the Rational Shipping Server for both CC and CQ, because de-installing either product from such a host will remove the Shipping Server that is used by both products and render the remaining product inoperable. If you must install both CCMS and CQMS with the Rational Shipping Server on the same host, ensure that you install CC first or uninstall both products if you ever uninstall either product.
NOTE: Administrators should be sure that site configuration files for typical host systems do not specify installation of the Rational Shipping Server. Any attempt to install CC on a host where CQ and the Rational Shipping Server is already installed will fail.

Back to the INDEX.
Determine if CCMS is installed on a particular machine.
On the CLI, run "multitool -ver". If you get an answer and not an error message, CCMS is installed.
On Windows only, the check can be done from a GUI. Start the ClearCase Doctor and Start Analysis. Under the section entitled "ClearCase Configuration" in the box called "ClearCase Windows Configuration", see if it says "Has MultiSite administrative services installed".

Back to the INDEX.
Rename or remove a shipping class.
Updated: 03/02/12
Version: 7.0.1.8
Once you add a shipping class definition in the CCMS Control Panel, there's no way to rename or delete it from there. Moreover, if you try to create another shipping class with the same name, but different case sensitivity, when you click OK to save the changes, your new class won't be created.
To rename or remove a class, edit the registry: HKEY_LOCAL_MACHINE\SOFTWARE\Atria\ClearCase\CurrentVersion\MultiSite\StorageClass

NOTE: If you try to change the case sensitivity of a class name in the registry, Windows will give an error message that the name already exists. So, to rename it, rename it to something other than the final name, then rename it again to the final name.

WARNING: If the class being renamed has already been used as part of a mkreplica command, the import and/or export packets will be sent to the location of the default class instead. It's unknown how one changes the class associated with a replica. The chreplica command doesn't support it.

Back to the INDEX.
Change the mastership of a CC object.
Updated: 07/31/12
Version: 7.1.2.4

The creation of new object implies mastership by the creating VOB. That mastership can be handed off to another replica. This is also needed if the replica in question is to be deleted. That is, one must hand off mastership of all CC objects prior to deletion. Must be in a view unless -view (CC 4.1) is used.

Branch instance mastership can be changed independent of the branch type mastership. However, to create element versions using that branch, the site must master the branch type. The branch type mastership cannot be transferred if there are any checkouts on that branch. 

	ct chmaster option(s) new-replica object-selector

# If retiring a replica:
	ct chmaster -all -obsolete_replica old-replica new-replica
NOTE: One cannot simply undo the mastership change by running the opposite chmaster. Once you've given up mastership, even if the packet has not been sent, only the new master can return mastership to you. That is, unless you use the   -force option.

Back to the INDEX.
Request/enable a change in branch mastership.

In CC 4.0, mastership of a branch can be requested by a remote site. Whether mastership is granted or not depends on a VOB Access Control List (ACL). The reqmaster subcommand can be used to display or set the ACL as well as requesting mastership. The VOBs involved must be at least FeatureLevel 2. Each VOB must be self-mastering, which was also a requirement to get them to the new feature level. As of CC 5.0, reqmaster doesn't work in a CCMS environment.

In general, several conditions must be met before gaining mastership of a branch. Is the developer allowed to request mastership (ACL)? Does the replica that your local replica thinks masters that branch indeed still master it? Are requests for mastership for that branch allowed? Is the branch locked? Are there blocking checkouts on that branch? If all those conditions are met, the change in mastership for that branch instance will proceed. If using UCM, you cannot request mastership of branches that are associated with streams.

The request for mastership does not take the form of a syncreplica, but rather an RPC call to the remote VOB. If mastership is granted, a syncreplica -export is performed at the remote site and the local site will process that packet based on its local handling criteria. That is, that packet can either be imported manually, imported at a designated time based on crontab entries (also schedule or at) or imported automatically using a RECEIPT-HANDLER. The developer requesting mastership is NOT notified when the change in mastership occurs, which is a good reason to use a RECEIPT-HANDLER. See step (5) of "Create an initial replica."

NOTE: Because the initial request is an RPC call it won't work across a firewall. To get it to work you would have to write a utility that would place the change in mastership command inside a file that gets sent to the remote site via a sync packet. The packet would need to be processed at that end by a special storage/shipping class and custom receipt-handler. The custom, remote receipt-handler on the remote end would execute the change in mastership and then generate a sync packet back to the originating site.

Determine/modify the VOB's ACL.

The VOB's ACL is there to set up who can request mastership changes. By default, a VOB's ACL is Read only for Everyone. By default, mastership requests are allowed for all instances of a branch type. The following assume you are inside a VOB. 
  # ct describe replica:relica-name
  # ct describe brtype:branch-name
  # ct describe element@branch-path
To set access on a VOB's ACL: 
  # mt reqmaster -acl -edit replica:relica-name
Possible combinations include an identity-specification and access-level. The identity-specification can be one of the following:
Everyone: Allow everyone in at the given access level.
Domain:domain Allow everyone in the specified domain in at the given access level.
Group:domain/group Allow everyone in the specified domain/group in at the given access level.
User:domain/group/user Allow the specified domain/group/user in at the given access level.
The access-level can be one of the following:
Read Read only access to the VOB's ACL.
Write Write access to the VOB's ACL.
Change Can request branch change in mastership.
Full Same as Read,Write.
Multiple access levels can be given for an object as long as they are comma separated with no spaces: Full,Change. The above ACL modification merely sets up who can modify a replica's ACL or request mastership changes. Once the permissions have been set properly, one still needs to "enable" mastership requests. At each replica: 
  # mt reqmaster { -enable | -disable } replica:replica-name
To allow/deny a mastership request on a branch or branch type: 
CC 4.2-:
  # mt reqmaster { -deny | -allow } -instances specific-branch
CC 5.0+:
  # mt reqmaster { -deny | -allow } specific-branch

  # mt reqmaster { -deny | -allow } brtype:branch

Enable requests for branch mastership.

1) Replicas need to be self mastering.
2) Replicas need to be at FeatureLevel 2.
3) At each replica, modify its ACL accordingly via "mt reqmaster -acl -edit ...".
4) At each replica, deny access to specific branch or branch-types via "mt reqmaster -deny ...".
5) At each replica, enable requests for mastership via "mt reqmaster -enable ...".

Request mastership of a specific branch during development. 

  # mt reqmaster element@branch-path
Note that the developer didn't need to know about or specify a replica name. CC will determine the master and send off an appropriate request.

NOTE: In CC 4.0, mt commands have been added to the ct repertoire. The upside of that is that a developer needn't care nor know about multitool and can simply use ct for all command-line work. However, not all the commands are available through ct, so you still must know which ones are or are not.

WARNING: The reqmaster command does not work well if a firewall is involved. Transfers of data across a firewall are handled by the shipping_server installed on the firewall. Requests for mastership are sent as RPC calls directly to the remote site. To enable reqmaster across a firewall, you would need to open up port 371 for the requests and any other ports for the replies (possibly 2048+). It can get ugly...

Back to the INDEX.
List masterships.

New in CC 4.1. Generate a listing of which replicas in a family master which objects. 
  # mt lsmaster replica
Options:
-kind object-kind[,...] Limit the listing to a specific type of object, such as brtype.
-fmt format-string See the fmt_ccase man page for output formatting options.
-view view-tag Use a view other than the default, which uses your current view context.
-inr.replica { -all | replica[,...] } Use a specific replica (or all replicas) to retrieve information.

The lsmaster command needs the name of a replica on which to report. If the command is issued in a VOB, simply give the short name of the replica. If the command is issued outside of a VOB, give the vob-tag in the selector: replica@vob-tag. If you want other replicas to supply the information, and not the replica on which you are generating the report, use the -inreplica option. This can be useful for asking the question, what objects do all the other replicas think that a certain replica masters.

Back to the INDEX.
Share MetaData types.

The following MetaData types can be shared between replicas: labels, attributes and hyperlinks. Note that branch types cannot be shared, element types are always shared, and trigger types are not replicated. To share MetaData, simply use the -shared option when creating the type. To avoid confusion, the local replica must master the object to which the type is being applied. Unless shared, instances of metadata can only be created in the replica that masters the metadata type.

NOTE: In the case of labels, even if the lbtype is shared and the branch to which the label is being attached is mastered locally, the element itself must be mastered locally as well. This is true unless the -pbranch was also used when creating the lbtype. That is, without -pbranch, the mastership of the element itself is checked (independent of who masters the branch). With the -pbranch option, only the branch mastership is checked. To confuse things further, if the element itself is mastered locally, the label can be attached to any branch independent of branch mastership.

NOTE: In the case of hyperlinks, if the hyperlink type is shared, instances can be created between any two objects in any replica, regardless of the mastership of that object. 
  # ct mk??type -shared type-name
Once a type has been shared, it cannot be converted to unshared, nor can you go back in and add the -pbranch option (in the case of labels). Also, the MetaData type property called "instance mastership" (CLI) or "Mastership kind" (GUI) shows up in a type's description/properties only after the a VOB is actually, already replicated.

Back to the INDEX.
Find all elements mastered by a site.

The lsmaster command that is usually used to determine the mastership of an object is view dependent. If an element is "hidden" to the current view, it won't show up in the listing. To see all elements mastered by a site, use a combination of "find" and "describe". Unfortunately, this command shows all masterships of all elements. 
On Windows:
  # ct find -all -exec "cleartool describe -fmt \"%[master]p %n\n\" \"%CLEARCASE_PN%\"" | findstr replica
On Unix:
  # ct find -all -exec 'cleartool describe -fmt "%[master]p %n\n" $CLEARCASE_PN' | grep replica
To find only those elements seen by the current view: 
  # mt lsmaster -kind felem -fmt "%n\n" replica
Back to the INDEX.
Determine the mastership of an object.
Updated: 05/04/16
Version: 7.1.2.14 

	ct describe -fmt "%[master]p" object-selector
Back to the INDEX.
Retransmit a missing packet.

Must be VOB owner, root (on UNIX) or in the clearcase group (Windows).

When an exporting site sends a packet out, it assumes that the packet was successfully integrated into the remote VOB and updates its own epoch table. There are several reasons why a packet did not reach its destination, but when the next update arrives you are likely to get "packet was not applied". In this case, the exporting site must retransmit the missing information.

To allow the system to choose the correct epoch numbers necessary to "roll-back" the epoch table to a certain point in time, use the following. The admin at the importing end needs to run lshistory on their end to determine the date of the last good import. 
At the import end:
  # ct lshistory replica:replica-name
At the exporting end:
  # mt recoverpacket -c "Retransmitting some packets." -since time replica-name
The time can take many forms, such as day-of-the-week, month, H:M:S, etc... Be sure to account for any time-zone differences. Consult the CCMS manual for details.
To manually choose the epoch numbers to which you should roll-back, the admin at the importing end informs the exporting admin of the last epoch number rcvd. 
At the import end:
  # mt lsepoch replica:export-replica-name
At the export end:
  # mt chepoch import-replica-name export-replica-name=number-given-by-import-admin

ex: mt chepoch  remote_replica  local_replica=100
As of CC 4.0, one can let the system decide what epoch numbers to set by querying the remote site directly. The following command will contact the remote site and set the local epoch numbers to be the actual ones at the remote site. At the export end: 
  # mt chepoch -actual import-replica-name
For the last two scenarios where recoverpacket was not run, once the epoch numbers are reset, one can simply wait until the next scheduled sync or manually syncreplica.

Back to the INDEX.
List any packets that might be in a shipping bay.
If an automatic syncreplica is invoked each time a new packet arrives in a site's shipping bay, there should never be any packets to list. However, if one is doing manual syncreplicas at a site, the following command will list the full pathnames of any packets in the shipping bay. 
  # mt lspacket
Options:
-s.hort List only the pathname of the packet.
-l.ong Also list the oplog IDs (epoch #s) and creating replica's OID.
packet-name Limit the listing to the named packet. Must appear after any options.
NOTE: Incoming packets inherit their owner and group permissions from the storage incoming bay.

Back to the INDEX.
Manually create a shipping order.
Each packet that gets transmitted from site to site has a shipping order associated with it. The mkorder command can be used if a packet was generated using "mkreplica -out" or "syncreplica -out". In addition, a shipping order can be generated for any arbitrary file that needs to be sent via the CCMS system. The generated shipping order needs to reside in the directory with the "packet". The mkorder command is stand-alone and lives in ccase-home-dir/etc on UNIX and ccase-home-dir\bin on Windows. 
  # mkorder -data packet-name destination-hostname
The output will be a file of the name sh_o_packet-name in the current directory. If packet-name contains any colon ":" characters, mkorder will convert them to dots "." automatically so that Windows will accept the shipping order filename. The mkorder command does not use a CC or CCMS license.
Options:
-scl.ass   class-name Use the shipping bay for the the storage class class-name.
-shi.p -cop.y Place the new shipping order and a copy of packet-name in the shipping bay.
-fsh.ip [ -cop.y ] Same as -ship, but shipping server is invoked immediately. The -copy option is optional.
-out   order-name Use order-name instead of the default sh_o_packet-name
-pex.pire   date-time Specify a time at which the store-and-forward facility stops trying to send the packet. Default is 14 days. Never expire is 0. See the syncreplica man page for date-time syntax.
-not.ify   email-address The delivery-failure message is sent to this address.
NOTE: If a file of the same name already exists at the remote site, the remote shipping_server will automatically rename the new incoming one to filename.1.

Back to the INDEX.
Transmit packets generated using -ship.
If a packet and shipping order are generated using the -ship option of mkorder or syncreplica, the packet and associated order are left untransmitted in the outoing shipping bay. If one then does a syncreplica, it will generate a new packet which is empty so is immediately deleted. So, to send packets generated using -ship, one needs to invoke the shipping_server manually. 
  # shipping_server { -poll | /path/shipping-order }
The shipping_server lives in /usr/atria/etc on UNIX and in ccase-home-dir\bin on Windows. The -poll option will assume the outgoing directory of the default shipping bay unless the option "-sclass classname" is given.

NOTE: Because the packet will be deleted when delivered, on UNIX, the user must own the data files being sent. On both Windows and UNIX, the user must have write and execute permissions on the directory where the shipping order resides.

Back to the INDEX.
List epoch information.
The epoch (oplog ID) is the number of operations performed at a site. Since each event is numbered, each site keeps track of which events have been sent and which events need to be sent (created since the last syncreplica). Each site always knows exactly at what epoch number it currently is and what epoch number it has rcvd from a remote replica. However, each site can only know that it has sent changes to a remote replica and not whether those changes were actually implemented. That is, a site's epoch table entries for other sites is only an estimate of what it thinks the other site knows about it.
The default for lsepoch is to list the epoch table of the current VOB. Unknown if lsepoch is available from either a Windows or UNIX GUI.
From the CLI: 
  # mt lsepoch
Some useful options:
-invob   vob:vob-tag Specify a VOB other than the current.
[replica:]replica-name[@vob-tag] Only list the row for the specified replica.

In the following example, there are 3 sites in this CCMS family: replica-name siteA, siteB & siteC. The output of the lsepoch command looks like: 

  # mt lsepoch

Oplog IDs for row "siteC" (@ siteC-server)
      siteB=221
      siteA=709
      siteC=653
Oplog IDs for row "siteA" (@ siteA-server)
      siteB=504
      siteA=950
      siteC=653
Oplog IDs for row "siteB" (@ siteB-server)
      siteB=504
      siteA=709
      siteC=653
The output of lsepoch is lines of ascii text. The rows can be mentally arranged in a visual format that better illustrates the information.
  updates originating at siteA updates originating at siteB updates originating at siteC
siteA's own status 950 504 653
siteA's estimate of siteB 709 504 653
siteA's estimate of siteC 950 221 653
In this example we assume the lsepoch was run from siteA. The first row in the table tells us that siteA knows it has generated 950 events, knows about 504 events at siteB and 653 at siteC. The second row tells us that siteA has yet to update siteB with epochs 710-950, assumes that siteB is up-to-date with itself and thinks that siteB is up-to-date with siteC. The third row tells us that siteA has already updated siteC with its events, thinks that siteB does not have all of siteC's events and assumes that siteC is up-to-date with itself.
NOTE: If a replica has been removed from the family, its name will still show up in the lsepoch as replica.deleted. This is by design for troubleshooting purposes and there is no way to filter them out with simple CC commands.

Back to the INDEX.
Create a custom packet.
Custom packets can be anything you want to send electronically. In fact, the packet being sent may have nothing to do with CC. That is, CCMS can be used to automate non-CC file transfers between distant computers. You just need to create a CCMS shipping order for it.
The creation of custom packets usaully goes hand-in-hand with the setup of a custom storage class. The custom storage class at the remote site will have a custom receipt-handler that knows how to process your custom packet when it arrives. 
  # mt mkorder -data filename -fship remote_server
You can use either -ship or -fship. Each has a sub-option of -copy. The -copy option will copy the filename to the outgoing shipping bay and send that one. The -ship option MUST use the -copy option. If you specify -fship without -copy, mkorder will create the shipping order for your file and then delete the file after successful transmission. You can optionally have -fship make a copy of the file first.

Back to the INDEX.
Determine the contents of a sync packet.
The "dump" option is available, but not supported yet. Note that without the -long, the output of this command-option is limited to the CC operation that produced the new epoch number. Also, to get useful information about the elements themselves, you must be sitting in the VOB pertaining to the sync packet. 
  # mt lspacket -dump -long packet
Back to the INDEX.
Compress synchronization packets.
Outgoing packets can be automitically compressed by CCMS and decompressed at the rcving end. Automated compression by CCMS can only be done as part of a scheduled job. Both Windows and Unix use ccase-home\etc\gzip. The following examples assume your scheduled job for sending sync packets is "Daily MultiSite Export".
On Windows, start the ClearCase Administration Console and go to My Host->Scheduled Jobs->Daily MultiSite Export. On the Parameters tab add "-compress" to field entitled "Use the following arguments".
On Unix, run the command "ct schedule -edit". Under the job "Daily MultiSite Export", add "-compress" to the line called "Job.Args".

Back to the INDEX.
Create an initial replica.
This assumes you already have a working VOB at SiteA. In the following, SiteA is the site with original VOB and SiteB is the site that will get the new replica. It assumes that CCMS was installed during the install of ClearCase.

1) At SiteA, give the original VOB a mnemonic replica name; something other than "original". Avoid hyphens in the name. 
  # mt rename replica:original@SiteA_vob-tag SiteA_replica-name
2) Create the initial packet. Ensure the shipping bay at SiteB has enough space to rcv the entire VOB.

NOTE: The default rcving bay on UNIX is /usr/atria/shipping, which is linked to /var/adm/atria/shipping. On Windows, it's %ATRIAHOME%\var\shipping. On UNIX, if there isn't enough space there, move the shipping directory somewhere else and recreate the link at /usr/atria/shipping. Though the storage bays can be set up anywhere, the incoming and outgoing subdirectories need to be on the same file system. Alternate shipping bays can be assigned on a VOB by VOB basis using shipping classes.
Replicas should NOT be created in the same region as each other, nor should they be mounted on the same machine even if in different regions. The export packet can contain more than one VOB to replicated. Simply give additional arguments similar the final one and all will be sent over at the same time. IP addresses can be used in lieu of hostnames.
While one has the ability to create multiple replicas in a single command, they all need to be copies of the same VOB. That is, in a single command, you can send a VOB to many different sites, but you cannot send many different VOBs to a remote site. 
  # mt mkreplica -export -nc -workdir temp-storage-area -fship SiteB_hostname:SiteB_replica-name@SiteA_vob-tag [ SiteC_hostname:SiteC_replica-name@SiteA_vob-tag ]
Options used:
-exp.ort Duplicate an existing VOB.
-wor.kdir   temp-storage-area Specify a temp area large enough to store an entire copy of the VOB. It cannot exist already and will be deleted after the packet is created.
-fshi.p Invoke the shipping server immediately.

Additional options:
-sh.ip Generate a packet, but don't send it anywhere yet.
-max.size   size(k, m, or g) An upper limit to the packet size in kilo, mega or giga bytes.
-pex.pire   date-time Sets a time after which the store-and-forward facility stops trying to send the packet. Default is 14 days. Never expire is 0. See the syncreplica man page for date-time syntax.
-tap.e   tape-device Send the output to a tape device instead of the shipping bay. This option is obsolete as of CCMS 5.0.
-scl.ass   class-name Use the designated storage class instead of the default.
-out   packet-name Use the designated packet-name instead of the default.
-notify   email-address The delivery failure message is sent to email-address.
NOTE: If -maxsize is not specified and you are using -ship or -fship the max size is simply the space limit of -work. For -out, the max size is 2GB. For -tape, there is no assumed max size.

3) At SiteB, ensure the packet arrived ok and is the correct size. Import the new replica. The SiteB_replica-name won't exist yet. The import phase will create a VOB with that replica name. If importing on Windows, enclose the packet-name in double-quotes. The final directory of temp-storage-area will be created by mkreplica. If the originating site had remote storage pools, those pools will be created locally unless the   -pooltalk option is used. Also, any pool parameters that were customized at the originating site will be set to default unless   -pooltalk is used.
NOTE: The Set VOB interop mode. VOB msdos text mode quality is not replicated. If the remote VOB is used in an interop environment (or vice versa), the VOB replica at the other site does not necessarily need to be in the same mode. 
  # mt lspacket -short
  # mt mkreplica -import -workdir temp-storage-area -tag SiteB_vob-tag -public -preserve -vob SiteB_vob-storage-area packet-name
Options used:
-imp.ort Create a new replica.
-wor.kdir   temp-storage-area Specify a temp area large enough to store an entire copy of the VOB.
-tag   vob-tag Give the new replica a mount point. Does not need to be the same as the original vob-tag.
-pre.serve Use the user (UID) and group (GID) names of the original replica.
-vob   vob-storage-area Give the new replica a home.
Other options:
-npr.eserve The user doing the import owns the elements.
-nca.exported (UNIX only) Assign an export-ID to the new VOB to ensure no "stale NFS handle" across reboots.
-ign.oreprot Complete the ownership-preserving import even if permissiom issues arise.
-poo.ltalk Specify pool locations and scrubbing parameters other than the defaults.
-vre.plica   replica-name Specify the replica to be imported if many are bundled in the incoming packet.
-tap.e   tape-device Look in tape-device instead of a shipping bay.
-reg.ion -opt.ions -pub.lic -pas.sword -hos.t -hpa.th -gpa.th See mkvob for explanations.
-stgloc   { storage-location | -auto } Instead of using -vob, you can specify the vob-storage area by using a registered storage location. The -auto option will select the location automatically.
-per.ms_preserve   [ -nprompt ] New in CC 2003.06.00. Preserve permissions but not ownership. Can optionally suppress the prompt.

NOTE: See Replica/element ownership/permissions for more details on -preserve, -npreserve, and -perms_preserve.

NOTE: If the export phase used the -maxsize option and many packets were created for a single replica, one only need specify the first packet, the one ending with "_1", when doing the import. If all the needed packets are in the same directory, CCMS will automatically find the rest of the set.

4) At both sites, place the receipt handler in a common location. 
  # cp /usr/atria/config/multisite/sync_recpt.sh /var/adm/atria/config
5) Set up the receipt handler. This will make it so that packets are automatically processed as soon as they are rcvd. As root at each Site, uncomment the following line in /var/adm/atria/config/shipping.conf on UNIX: 
  RECEIPT-HANDLER  -default /var/adm/atria/config/sync_recpt.sh
NOTE: In CC versions prior to 3.2.1, the above line was written as RECEIPT_HANDLER. Simply change the underscore to a dash when uncommenting the line.

The default UNIX shipping.conf and explanation thereof is stored in shipping.conf.template. On Windows, go to the MultiSite Control Panel and fill in the Receipt Handler Path with ccase-home-dir\config\cron\sync_recpt.bat for CC 3.x and ccase-home-dir\config\scheduler\tasks\sync_receive.bat for CC 4.x.

6) Set up automatic synchronizations.
On UNIX CC 3.x, as the VOB Administrator at each Site, add a line similar to the following to the crontab, which runs replica synchronizations. This example crontab entry will sychronize the VOB every 4 hrs on the 1/4-hour during the day. The output is sent to /dev/null because syncreplica will send output even if successful. Some sysadmins monitor the output of cron jobs. Sending them mail every 4 hrs is too much. For example, at SiteA: 
To sync just one VOB:
  15 8,12,16,20 * * * /usr/atria/config/multisite/sync_send.sh SiteA_VOB-tag SiteB_replica-name > /dev/null
To sync all VOBs:
  15 8,12,16,20 * * * /usr/atria/config/multisite/sync_sendall.sh > /dev/null
To run syncreplica independent of a script:
  15 8,12,16,20 * * * /usr/atria/bin/multitool syncreplica -export -fship SiteB_replica-name@SiteA_vob-tag > /dev/null
The max packet size is set in the shipping.conf file and is independent of class.

On UNIX or Windows CC 4.x, the "schedule" command takes the place of "at" and "cron". See the schedule command for general details. The CC Reference Manual has details on job database options. Installion of CCMS automatically places CCMS tasks in the job task database. The entries are already in the "jobs scheduled" database, they just need to be turned on. 
  # ct schedule -edit -schedule

In Windows CC 3.2.1-, use the "at" facility to schedule sychronization jobs. Invoke either the sync_export.bat to export all VOBs on the system or sync_export_one.bat to export a specific VOB. The disprun utility is obsolete as of CC 5.0. 
To sync just one VOB:
  at 03:00AM /every:su <ccase-home-dir>\bin\disprun sync_export_one \vob-tag remote-replica
To sync all VOBs:
  at 03:00AM /every:m,w,f <ccase-home-dir>\bin\disprun sync_export
On Windows, the max packet size is set in the CCMS Control Panel and is independent of class.

7) Use the epoch_watchdog script in a scheduled job to ensure epoch numbers are not rolled back without restorereplica.

8) Test the system. Change something at both Sites, wait until the automatic syncreplica happens and then check to ensure the changes from both sites propogated properly.

Back to the INDEX.
Remove/retire a replica.
Normally a VOB is removed by simply running rmvob. However, replicated VOBs generally master some CC objects locally. The mastership of these need to be turned over to another site before the VOB can be removed. In the following steps, SiteA is where the replica is to be removed and SiteB is the new master of that replica's objects.

1) At SiteA, complete all work in any view. See "Checkin all elements from all views".
2) At SiteA, relenquish mastership of everything to SiteB. Or at SiteB, TAKE mastership of everything from SiteA (only if SiteA no longer exists). 
  # mt chmaster -all -long SiteB-replica-name
-or-
  # mt chmaster -all -obsolete_replica SiteA-replica-name SiteB-replica-name
3) At SiteA, sync the replica with SiteB. 
  # mt syncreplica -export -fship SiteB-replica-name
4) At SiteB, ensure the change in mastership has been successfully integrated. 
  # mt syncreplica -import -receive
Test the new masterhsip.
5) At SiteB, remove the name of the replica to be deleted. 
  # mt rmreplica SiteA@SiteA-vob-tag
6) At SiteB, tell the remaining replicas that SiteA is now out of the loop. If SiteB is the last replica in the family, after step (5), it will simply be a non-CCMS VOB and will only use a CC license. 
  # mt syncreplica -export -fship other-replica-names
7) At SiteA, remove the VOB the normal way. 
  # ct rmvob -f vob-storage
WARNING! The removal of a replica, even an unused one, can have undesired results in a UCM environment. For example, if a user has performed a deliver, but not completed it yet, the deliver will fail to complete if the replica is removed in the mean time.

Back to the INDEX.
Manually sync replicas.
From time to time, it may be necessary to manually sync replicas inbetween the times in which they would have been synced automatically; see Create an initial replica. At the exporting site: 
  # mt syncreplica -export -fship remote-replica-name@local-vob-tag
At the importing site: 
  # mt lspacket -short
  # mt syncreplica -import full-packet-pathname
Other options:
-max.size   max-packet-size On export, limit packet sizes to max-packet-size(k, m, or g). See warning below.
-max.size   max-packet-size   -limit   num-packets Same as above, except limit the total number of packets to num-packets.
-scl.ass   storage-class Export or import, specify the storage class. Available only for -ship and -fship.
-pex.pire   date-time On Export, designate how long store-and-forward should retry sending. Default is 14 days. Never expire is 0. See the syncreplica man page for date-time syntax.
-not.ify   email-address The deliver-failure message is sent to email-address.
-sh.ip On export, let store-and-forward create the packet in the outgoing bay but not deliver it.
-fsh.ip On export, let store-and-forward create the packet and send it immediately.
-tape   raw-tape-device On export, create the packet on the raw-tape-device. This option is obsolete as of CCMS 5.0.
-out   packet-file Designate your own packet-file for ftp or other transmission later.
Alternatively, at the import site, you can simply use the -receive option in lieu of the full-packet-pathname to process all packets destined for local VOBs. If you encounter "packet was not applied", see recoverpacket.

WARNING: If a single version's cleartext is larger than the value specified for –maxsize, syncreplica creates the packet anyway 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.

Back to the INDEX.
Change the hostname associated with a replica.
Each replica's database knows on what hostname a replica resides; this allows you to send updates to that remote site by simply invoking the replica name. If a replica's hostname changes, the replica's database needs to be updated accordingly. The change will be propogated at the next scheduled sync. 
  # mt chreplica -host new-hostname replica-name
Back to the INDEX.
Replica/element ownership/permissions.
There is difference between ownership and permissions. Ownership refers to the user and group that owns the element. Permissions refer to whether a user has read, write, or execute permissions. When creating a new replica (mkreplica -import), you must choose a preservation mode: ownership and permissions, just permissions, or neither. Note that in some CC man pages the term "ownership" is synonymous with "identity".
1) Replicas in a family can only be ownership-preserving if they share the same domain (Windows) or use the same NIS map (Unix). The UID/GID can be forced equal across different Unix domains. There is no way to force the UID/GID across disparate Windows domains, even if the usernames and group names are the same. See the -preserve option for mkreplica or chreplica. There are no like restrictions on just permissions preservation (-perms_preserve).
2) Not all replicas in a family have to be ownership-preserving even if there are others in the family that are. That is, there can be a subset of the replica family that is ownership-preserving while others are not. However, there can only be one such subset for a given family even if some replicas do not exchange update packets with other replicas.
3) Non-ownership-preserving replicas ignore ownership/permission updates from ownership-preserving replicas. Likewise, changes in ownership/permission in non-ownership-preserving replicas are not propogated to other replicas.
4) The owner and primary group of a new replica is the user/group performing the import, regardless of whether the import is ownership preserving or not. That is, ownership preserving only refers to element security and not VOB security.
5) Initial permissions on imported elements are the same as those of the original replica regardless of ownership-preserving status.
6) If a replica is added to an ownership-preserving subset of a replica family, there is no immediate affect on that replica's currrent ownership/permissions. However, future ownership/permission changes in ownership-preserving replicas will have an affect.
7) New in CC 2003.06.00, a replica can be created that preserves permissions, but does not preserve ownership. Use the new -perms_preserve option to split the difference.

The following command to change whether a replica is ownership-preserving must be entered at the site that masters that replica. Must be the replica owner, root (Unix) or in the clearcase group (Windows). 
  # mt chreplica { -preserve | -perms_preserve | -npreserve } replica-name@vob-tag
Back to the INDEX.
Determine the replica name of a VOB.
Updated: 03/28/13
Version: 7.1.2
A simple describe command of a VOB will show a replica name whether or not the VOB is MultiSited. 
	ct describe vob:vob-tag
...
    replica name: replica-name
...
If you want to see the replica name only: 
	ct describe -fmt "%[replica_name]p\n" vob:vob-tag
In CAL: 
	$current_replica = $vob_o->ThisReplica;
NOTE: The lsreplica subcommand does not have an option to show you just the current VOB's replica name and instead will show you all the replica names associated with that VOB's family in alpha-numeric order.

Back to the INDEX.
Move a replica.
Follow the procedure in the CC Admin Manual for moving VOBs or see "Move a VOB". Once the VOB has been moved, one simply needs to tell CCMS that the replica's host has changed: 
  # mt chreplica -host new-hostname replica-name
Back to the INDEX.
Rename a replica. 
  # ct rename replica:old-name new-name
Back to the INDEX.
List VOB replicas.
Updated: 01/09/12
Version: 7.0.1.8
In UNIX 3.x xclearcase, Admin -> VOB... -> Admin -> select a VOB -> VOB -> List replicas.

In UNIX 4.x xclearcase, Admin -> VOB... -> select a VOB -> VOB -> List replicas.

In UNIX/Windows clearvobadmin, not possible.

From the CLI: 
  # ct lsreplica
Some useful options: List remote family members excluding the local replica itself.
-l.ong Include information on the replica's host.
-s.hort List only the replica names.
-fmt   format-string Format the output. See fmt_ccase in the CC Reference Manual.
-invob   vob-tag Restrict the listing to the replicas of a single VOB.
-sib.lings

From CAL: 
	$vob_o = $CC->VOB("\\My_Vobtag");
	$vob_o->ThisReplica;
Warning: The CLI lsreplica will return "original" if the current VOB isn't replicated, whereas CAL ThisReplica returns nothing.

Back to the INDEX.
List a replica's properties. 
  # ct describe replica:replica-name
New in CC 5.0, the OID of the replica can be used to reference the replica. The specified replica must be at the current site. The replica object OID is the same as the VOB replica UUID. 
  # ct describe oid:replica-oid
Back to the INDEX.
Indicate whether a replica's sibling has IP connectivity.
New in CC 5.0, entries can be added to a replica's properties sheet for informational purposes that indicates which of its siblings have direct IP connectivity. 
  # mt chreplica { -isconn.ected | -nconn.ected } sibling-replica-name
Back to the INDEX.
Determine the incarnation number of a replica.
The replica incarnation is the last time the replica was restored with the restorereplica command. The incarnation is set to 0 when the replica is created and remains 0 until a restoration occurs. Each replica keeps a record of the incarnation of each other replica in the VOB family. During packet export, the incarnations of the target replicas are recorded in the packet. The syncreplica –import command at the importing replica checks the incarnation in the packet. If the incarnation in the packet is earlier than the importing replica’s own record of the sending replica's incarnation, the packet is not imported. The incarnation number, if not zero, is the date of the last restorereplica. 
  # ct dump replica:replica-name
Back to the INDEX.
Find out about unfiltered replica types.
In a VOB there are several different types of metadata, including a "hidden" one called rptype (replica type). Replica types have a property called filtered or unfiltered. At one time Rational toyed with the idea of having partially replicated VOBs. However, replicas types and their properties (namely filtered or unfiltered) associated with that partial replication idea were never fully implemented. So, it's possible to run across some of these terms in obscure locations within a VOB. Just ignore them.

Back to the INDEX.
Find all replicated VOBs in a CC region.
There is no single command that can accomplish this. However, the following Perl script can. If a VOB has more than one replica name listed, it's replicated. Your Perl executable may be different. 
  # perl -e "foreach (`cleartool lsvob -s`) { print \"\n$_\"; system(\"cleartool lsreplica -s -invob $_\"); }"
Back to the INDEX.
Switch a replica to managed mode.
Updated: 02/19/13
Version: 7.1.2
As of CC 2003, by default it isn't possible to run a syncreplica command from a host that is not the VOB server. You can specify the "-host" option, but that requires the replica be switch to "managed" mode. The following command will switch the replica's mode. 
	mt syncserver -manage -vob vob-tag
Notes:
If a replica is in managed mode, the shipping_server is not utilized. All ex/import commands must be run explicity by hand or in a custom scheduled job.
A replica family can have both managed and non-managed replicas, but a given replica is all in managed or non-managed mode. That is, a given replica cannot be in managed mode for one sibling and non-managed mode for another sibling.

Back to the INDEX.
Run syncreplica from a remote host.
Updated: 02/19/13
Version: 7.1.2
As of CC 2003, by default it isn't possible to run a syncreplica command from a host that is not the VOB server. You can specify the "-host" option for exports and the "-to" option for imports, but those require the replica be in "managed" mode. See Switch a replica to managed mode.

Back to the INDEX.
Get details about oplog events.
Updated: 04/26/13
Version: 7.1.2
Every change to a VOB is an event. Events are recorded in the replica's oplog. Those events are then replayed at other sites. The following command will give details about the events in the oplog. Be sure to use filters that limit the output, as the output can be very large. 
	mt dumpoplog -vreplica replica-name -since date-time > replica-name.log
That command is not currently in the CCMS admin manual. See https://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/index.jsp?topic=/com.ibm.rational.clearcase.cc_ms_ref.doc/topics/mt_dumpoplog.htm

Back to the INDEX.
Get a replica's history
Updated: 03/13/15
Version: 8.0 
	ct lshistory replica:replica-name@vob-tag
Back to the INDEX.

ejostrander@cox.net
Return to the home page .

This page last modified: 05/04/2016