Home

How do I

Soft - is your software and documentation
Asset - is something that must be protected
Management - is what we do
Enterprise - is the capability
Computing - is the power
Services - are what we provide


ClearQuest MultiSite “How do I” covers: (Last updated 16-Oct-09)

Ø Job Scheduler – setting up to handle ClearQuest packets, etc...

Ø Mastership – changing between sites, etc...

Ø Replicas – changing hostname for a replica database, etc...

Ø Audit trail packageunderstanding, etc...

Ø Code page – changing, etc...

Ø Firewalls – setting up, etc...

Ø Problems & Issues – rmreplica, etc...

Table of contents

ClearQuest MultiSite “How do I” covers: (Last updated 16-Oct-09) 1

Table of contents. 1

Job scheduler. 2

1.       How do I – set up the ClearCase Job Scheduler to handle ClearQuest packets. 2

Mastership. 3

2.       How do I - change Mastership from one ClearQuest site to another 3

3.       How do I - resolve an unable to Save as Default after user's mastership has been changed issue. 4

4.       How do I – resolve unable to designate a startup query after user's mastership has been changed issue. 4

Replicas. 5

5.       How do I - restore a damaged ClearQuest MultiSite replica when using single-hub synchronization and a database backup is available. 5

6.       How do I – understand the “ERROR: 'ORA-00001: unique constraint violated' when using syncreplica after restorereplica” issue  5

7.       How do I - change the hostname for a ClearQuest MultiSite replica database. 6

8.       How do I – understand the failed condition error when performing a syncreplica import 6

9.       How do I - find the id block size, threshold, host for a ClearQuest replica. 7

Audit trail package. 7

10.     How do I – understand the Audit Trail package can no longer modify a record if mastership changes in a MultiSite environment 7

Code page. 7

11.     How do I – understand the considerations for Changing the Code Page in a ClearQuest MultiSite environment 7

Firewalls. 8

12.     How do I – understand the shipping server behaviour with Firewalls that time out idle TCP connections. 8

13.     How do I - limit the range of ports ClearQuest MultiSite would select to navigate a firewall 9

Problems & Issues. 10

14.     How do I - resend a previously generated MultiSite packet 10

How do I – understand the rmreplica does not allow user to re-use the replica name issue. 10

15.     How do I – understand how ClearQuest MultiSite - Stores History Dates in Coordinated Universal Time. 11

Rational ClearQuest software stores history dates for records in the history table of the user database. Changes to objects are recorded by inserting a row in the history table. The history table contains two date/time columns: action_timestamp and expired_timestamp. These time stamps have always been recorded in the local time of the database server, which is sufficient in a single site environment.  11

However, in a replicated deployment, where database servers are in different time zones, storing time stamps in the local time of the database server can cause actions to appear to have occurred out of order. For example, a defect might appear to be closed before it is opened or assigned before it is submitted. The solution to this problem is to store Rational ClearQuest history time stamps in Coordinated Universal Time (UTC).. 11

Documentation for UTC can be found in the UTC Whitepaper, which is located in the ClearQuest Information Center for 7.0.1.. 11

16.     How do I – understand why the MultiSite Deactivate example in documentation is incorrect 11

This issue has been identified as a ClearQuest documentation defect.. 12

 

Job scheduler

1.    How do I – set up the ClearCase Job Scheduler to handle ClearQuest packets

Using task schedulers for automated synchronization
When you use a scheduling utility, such as the Rational ClearCase scheduler, to execute Rational ClearQuest MultiSite commands, the scheduler process must have access to the Rational ClearQuest environment. In Windows, the user who runs the Rational ClearCase scheduler must also create the connection to the Rational ClearQuest schema and user database for performing the scheduled operations.

On computers running Linux or the UNIX system, the scheduled task must set up the Rational ClearQuest environment by running the cq_setup script prior to running the multiutil subcommands.

Note: This document assumes that the reader has ClearCase installed and has referenced the ClearCase Scheduler information documented in Chapter 12 of the ClearCase MultiSite Administrator’s Guide Version 2003.06.00.

1.     Create a new storage class & define routing Information

A.    How do I – Windows:

                                     I.        Select Start > Control Panel > MultiSite

                                    II.        In the MultiSite Configuration Information dialogue box:

a.     Under "Storage Classes", create a storage class called cq_default and point the Storage and Return bay paths to your designated directories.

b.     Under "Routing Information", define the Next Routing Hop and Destination Hostnames if packets will be shipped through an intermediate host for forwarding to the target host.

B.    UNIX:
Edit the following lines in the /var/adm/rational/clearcase/config configuration file "shipping.conf", adding the cq_default storage bay and identifying any routing requirements if needed.

STORAGE-BAY  -cq_default  /opt/rational/clearquest/shipping/ms_ship
RETURN-BAY   -cq_default  /opt/rational/clearquest/shipping/ms_rtn
ROUTE  <next-hop>   <host> <host> ...

Note: The storage and return bay pathnames above should already exist and should contain both “incoming” and “outgoing” subdirectories.

2.     Create new script files for the import and export operations.
Sample export script:

multiutil syncreplica -export -clan <Clan_Name> -site <source-replica> -family <family_name> -user <userid> -password <password> -workdir <temp-directory> -fship -sclass cq_default <destination-replica>


Sample import script::

multiutil syncreplica -import -family <family_name> -user <userid> -password <password> -sclass cq_default -receive

3.     Define new tasks in the Task Registry
Edit the task_registry file in the following directory, adding new entries to the bottom of the file for the import and export jobs (this example uses Task.Id: 102 and 103 which may need to be changed if those task ids are already in use).

A.    Windows: <clearcase-install-directory>\var\scheduler\tasks\task_registry

B.    UNIX: /var/adm/rational/clearcase/scheduler/tasks/task_registry
Note: that in the sample below:

                                     I.        The "Task.Name" is the name you will see in the Scheduler when you create your new job.

                                    II.        The "Task.Pathname" is the path to the script file that will run your MultiSite commands.
Sample task registry entries:
Task.Begin
Task.Id:       102
Task.Name:     "CQ Import"
Task.Pathname: "c:\Program Files\Rational\ClearCase\var\scheduler\tasks\CQImport.bat"
Task.End
Task.Begin
Task.Id:       103
Task.Name:     "CQ Import"
Task.Pathname: "c:\Program Files\Rational\ClearCase\var\scheduler\tasks\CQExport.bat"
Task.End

Daily MultiSite Shipping Poll job
The Daily MultiSite Shipping Poll job is predefined and will query/process all pending shipping orders sending packets to their next host for both ClearQuest MultiSite and ClearCase MultiSite.

Mastership

2.    How do I - change Mastership from one ClearQuest site to another

Mastership is achieved by running the multiutil chmaster command at the master site.

For example: There are two sites, SiteA and SiteB. SiteA has the working master schema repository and the user database is also the master replica. The requirement is that SiteB to be the working master schema repository and also the master replica of the user database.

 

To change mastership, first, back up all replica databases and the MASTR (schema repository). Then, use the multiutil chmaster command, at the master site, to perform the following changes:

1.     Change mastership of database records.

2.     Change mastership of Users and Groups.

3.     Update mastership of database replicas.

 

The correct syntax of the multiutil command is outlined below:
chmaster [-clan clan-name][–site site-name] –family family-name -user username [–password] password new-master-replica {{entity-selector... |{ –all [ –long ]|-workingmaster } [ –force old-master-replica ]} }

For more information on changing mastership and the chmaster parameters in ClearQuest 7.0, refer to the online help or go to the ClearQuest 7.0 information center. This information is also available in the ClearQuest MultiSite Administrator’s Guide in the 2003 release.

The following example commands will change mastership from SiteA to SiteB. In the example, the clan name is "CLAN2", the family name is "sampl", the user is "admin", and the password is blank.

1.     multiutil chmaster -cl CLAN2 -site SiteB -fam sampl -u admin "" SiteB -all -force SiteA
Note: This changes mastership of all the records in SiteA to SiteB.

2.     multiutil chmaster -cl CLAN2 -site SiteB -fam mastr -u admin "" SiteB -all -force SiteA
Note: This changes mastership of users and groups from SiteA to SiteB.

multiutil chmaster -cl CLAN2 -site SiteB -fam mastr -u admin "" SiteB -workingmaster -force SiteA
Note: This changes mastership of the schema repository from SiteA to SiteB.

3.    How do I - resolve an unable to Save as Default after user's mastership has been changed issue

When a user uses Save as Default in a record type, each field value is saved in the back-end as a separate value and defined with their current mastership. These values are stored at all sites during syncreplica operations. When a user has already saved a set of defaults, and their mastership is changed, the mastership of these default values remain untouched. Because of this, while they are able to load their existing defaults, when the user attempts to Save as Default again they will received an error similar to the following:

Error! To edit 'Headline;Defect' of Record type 'bucket', please contact someone at Site 'Lexington' and have them change mastership of this record to 'Boulder'.

Because ClearQuest is unable to modify the existing values, it inserts new values into the back-end and thus creates multiple rows for each default field value.

 

Solution

To resolve this issue it may be necessary for the user's mastership to be changed back to its original site in order to properly save a new set of defaults.

This issue has been identified as a product defect and has been logged under APAR PK36825.

A request for enhancement, RATLC00748184, exists that addresses the need for ClearQuest to simplify the process of changing mastership of users

4.    How do I – resolve unable to designate a startup query after user's mastership has been changed issue

When attempting this set a query to be the default query at startup, users might see an error message similar to the following:

Error! To edit 'STARTUP_BUCKET_ARRAY' of record type 'bucket', please

 contact someone at site 'old' and have them change mastership of the
 record to this site '´new'.

This error can occur when a user attempts to define a start-up query after his/her mastership is changed. There is a value in the back-end database that also needs to have its mastership changed in order for the user to resume defining start-up queries.

 

Solution

This problem is fixed by transferring mastership of STARTUP_BUCKET_ARRAY using the chmaster command. An example of such a command is:

multiutil chmaster -u admin "" -cl GSH -site SITE_A -fam SAMPL SITE_B "workspace:STARTUP_BUCKET_ARRAY(lead)"

The above command transfers the mastership of the STARTUP_BUCKET_ARRAY of the user lead from site SITE_A to site SITE_B.

A request for enhancement, RATLC00748184
, exists that addresses the need for ClearQuest to simplify the process of changing mastership of users so that changing the mastership of additional components is not needed.

Replicas

5.    How do I - restore a damaged ClearQuest MultiSite replica when using single-hub synchronization and a database backup is available

How do you recover a damaged database replica in a IBM® Rational® ClearQuest® MultiSite environment? How is this done if the database backup is available and MultiSite is using single-hub synchronization?

 

Cause

There is a damaged database replica in ClearQuest MultiSite environment that needs to be restored. Occasionally, this is required if a replica is damaged. This loss is usually due to a hardware failure, software failure, or human error.

 

Answer

To help guide you through resolving this problem, here is an example scenario of recovering from this situation.

EXAMPLE:
There is a total of three replicas:


Other MultiSite specifications:


Problem: For some reason,
USERDB1 for site B is damaged. At this time USERDB2 on site B is synchronized well with site A.

These steps will help to restore the replica B using the database backup:

1.     Restore the database set backup (MASTR, USERDB1, USERDB2) for site B, which was taken before the problem occurred.

2.     On site B run restorereplica based on family USERDB1.

3.     Syncreplica export and import between B and A.

4.     Syncreplica export and import between B and C. Although single-hub synchronization is in use, B is not talking to C for synchronization. After restorereplica you still need to synchronize between the restored site and the rest of the replicas in the family.

Repeat steps 2 through 4 for USERDB2. Then replica B is successfully restored from backup. The changes made on site B USERDB1 between the time of the backup and the time of the failure are not recoverable. All other data is back.

6.    How do I – understand the “ERROR: 'ORA-00001: unique constraint violated' when using syncreplica after restorereplica” issue

When running the multiutil command syncreplica -import to sync sites after running a multiutil restorereplica command, the following error occurs:

ORA-00001: unique constraint (<Oracle_user>.MASTER_SCHEMAREVS_REV) violated

 

Cause

This is caused by a schema being checked out in the restored schema repository database, before the running of the restorereplica command. This issue has been identified as a product defect under APAR PK46185.

 

Environment

This error occurs with databases hosted on Oracle

 

Resolving the problem

This defect is under investigation, and there is no permanent fix time. Schemas need to be checked in prior to running a restorereplica command.

WORKAROUND:

Restore the database set (schema repository and user databases) on the master site and undo schema check-out before re-running the restorereplica command. The -import commands to sites should successfully run.

7.    How do I - change the hostname for a ClearQuest MultiSite replica database

To change the hostname for a ClearQuest MultiSite replica database use the following command.


multiutil chreplica -cl clanname -site new site name -u username -p password -hostname new hostname -replica sitename.

8.    How do I – understand the failed condition error when performing a syncreplica import

When running a syncreplica import, the following error might occur:



Multiutil: Error: Exception: Failed condition: user_blocks[i].m_Field    
(AdIdBlockDb::available) <= master_blocks[i].m_Field(AdIdBlockDb::available)        
Location: ClearQuest Core:admultisite.cpp:2659


This error occurs when there is an variance between a user database and the schema repository of the affected site. The user database has back-end values that list having more Request IDs and Aux IDs than recognized by the repository.

This can be caused if backup and restore activity has been performed on the site, and the backup images used were not in sync. For example, the user database may have been restored with a backup image that was created with an earlier time or date than the image of the repository.

It is also possible that while backup processes are being executed, that users are still able to access the ClearQuest environment to make changes.

 

Solution

One method to fix this problem is to force all masterships at the site to the MASTER site, and to remove the replica. Once this is done, recreate the replica using a different name.

Note: While this method will likely fix the problem, it might be possible to implement an alternative fix with the assistance of IBM Rational ClearQuest Support. Please contact support with output of master_id_blocks and master_replicas from schema repository and rat_replicas, ratl_id_blocks and dbglobal from user database on the importing site. Based on this data, support may be able to provide an SQL fix to resolve the issue.

Preventing future occurrences

In order to prevent this problem, it is important to assure synchronization and integrity when backing up the database components of the site. For example, when performing a backup, the schema repository database and user databases should all be locked. It is also important to assure that all components of the site are restored simultaneously, as with any ClearQuest environment.

To correct this information based on current values

Please contact support with output from master_id_blocks and master_replicas from the schema repository and ratl_replicas, ratl_id_blocks and dbglobal from the user database on the importing site. Based on this data, ClearQuest support may be able to provide an SQL fix to resolve the issue.

Run these queries at the site where the import error occurred. This value will become the replica value in the next queries.

1.     From the schema repository:

select dbid from master_replicas where name = <site name> and family = <family>.

2.     From the schema repository:

select * from master_id_blocks where replica = <the replica id
from above> and family = <family> group by type order by base

3.     From the user database:

select * from ratl_id_blocks where replica = <the replica id from above> group by type order by base.  

select * from dbglobal

Grouping by type separates the blocks for stateful versus stateless records.
Ordering by the base should put each block of IDs in order making it easier to review the data.

9.    How do I - find the id block size, threshold, host for a ClearQuest replica

The lsreplica command with the -long argument lists detailed information about a replica and can be used to get the id-block size, threshold and hostname.

For example, to display the names of all replicas in the SAMPL family, run the following command at working master:

multiutil lsreplica -clan TRAINING -site s1 -u admin -p "" -fam SAMPL –long


This command returns output similar to the following:

Name: S1; Clan: TRAINING; Family: SAMPL; Host: vidyaxp; Status: NORMAL, NOT CONNECTED; Description: ; Block Size: 4096; Block Threshold: 1024

Name: S2; Clan: TRAINING; Family: SAMPL; Host: vidyaxp; Status: NORMAL, NOT CONNECTED; Description: ; Block Size: 4096; Block Threshold: 1024

Audit trail package

10. How do I – understand the Audit Trail package can no longer modify a record if mastership changes in a MultiSite environment

When running a ClearQuest MultiSite environment that includes the Audit Trail package, you cannot modify a record if master ship has changed. Attempting to modify the record results in the error:

ERROR! Execution of a hook failed during the action Modify. It
was the ACTION_COMMIT hook attached to the Task 186db000000009
The reason for the failure was: To edit 33559837 of record type
Audit TrailLog, please contact someone at site ANBU and have
them change mastership of the record of this site XYZ at
c:/Program
Files/Rational/Common/lib/perl5/site_perl/5.6.1/CQPerlExt.pm
line 1679

When a defect record that has the ratl_mastership different than the at_field_history.ratl_mastership, if you try to assign these defects to a user that is mastered in a different replica, the mastership of the defect tries to change, but fails because the at_field_history is mastered somewhere else.

Steps to reproduce problem:

1.     Setup a MultiSite environment using the SAMPL database.

2.     Add the Audit Trail package to the schema and the Defect record type.

3.     Create a record at the replica site.

4.     Change mastership to the master site.

5.     Sync between the sites.

Try to modify that record at the master site. It fails with the fore mentioned error.

 

Solution

The AuditTrail, eSignature, and various other packages rely on Action hooks to keep the mastership of a child record consistent with its parent. The multiutil chmaster command does not run as an Action, so these hooks are not invoked during execution of that command. As a workaround either disable the package or roll back the database to an earlier version of the schema.

This issue has been identified as a product defect and has been logged under APAR IC47823.

Code page

11. How do I – understand the considerations for Changing the Code Page in a ClearQuest MultiSite environment

The documentation in the ClearQuest 7.0 Installation and Upgrade Guide p. 142 states:

In a Rational ClearQuest MultiSite environment, to change the data code page at the master site and replicate the modified database, do the following:

1.     Back up your databases.

2.     Remove all replicas.

3.     Change the data code page at the master site.

4.     Scrub the oplogs.

This information can also be found in the ClearQuest 7.0 Information Center

In a Rational ClearQuest MultiSite environment, changing the data code page from any non-ASCII value might introduce incorrect data in your oplogs. For best results, remove all replicas, clean the database at the mastering site, scrub the oplogs, and then re-create your replicas.

 

Solution

If you are upgrading from a character set that is a subset of another, for example ASCII to Latin-1, you will not have to remove and recreate all replicas.

Here are some steps and issues to consider:

1.     Verify that the vendor database character set is set appropriately as listed in the Appendix B Table 25 of the ClearQuest 7.0 Installation and Upgrade Guide.
Note: If the database vendor character set is not correct to support the target code page, then the procedure as documented in the upgrade manual should be followed. This would involve creating a new database instance with the correct database vendor character set, and then copying the data into the newly constructed database instance.

2.     Run the codepageutil to verify that there are no offending records. If this is not run and there are some, you will have synchronization problems in the future. The remedy for this is to fix the records in the database

3.     Use the ClearQuest Maintenance Tool on the mastership site, to update the code page, and then perform a syncreplica.

4.     As with any schema change in a MultiSite environment, backup databases, stop all synchronizing, ensure all users are disconnected from all the databases (stop and restart database so there are no open connections), and ensure all sites are synchronized.

 

A request for enhancement (RFE) exists to change the code page on the working master, then replicate the change instead of recreating replicas. Is tracked by RFE number RATLC01016091.

Create Back-up files

Note: Always make new database back-ups of your schema repository and users databases prior to making schema changes and performing database upgrades. Failure to create back-up copies can limit your ability to recover from a an upgrade failure, design change issues or other unforeseen failure.

Firewalls

12. How do I – understand the shipping server behaviour with Firewalls that time out idle TCP connections

This technote explains how many firewalls have a time out period to terminate seemingly idle TCP connections which can prevent the successful transmission of large replication packets when using an IBM® Rational® ClearCase MultiSite® or ClearQuest MultiSite® shipping server.

 

Symptom

Many firewalls have a feature to reset TCP connections that have been idle for a specified period of time, which is often 1 hour.

When using MultiSite to replicate ClearQuest or ClearCase data, this idle reset will destroy the connection between administrative sockets on the sending and receiving shipping_server processes.

The shipping server logs on the receiving server may contain the following errors:

2006-05-07T02:25:42-07 shipping_server(28633)_C(28638): Error: shp_verify_request_receipt_V1: RPC: Unable to send; errno = Broken pipe
2006-05-07T02:25:42-07 shipping_server(28633)_C(28638): Error: A shipping_server RPC failed. Additional information may be available in the albd_log on the destination machine.

As a result of this issue, the shipping_server will report an unsuccessful operation after all the data has been transferred between the data transfer sockets, because the administrative hand-off cannot be completed.

 

Resolving the problem

The shipping_server uses 2 ports; one for communication and one for the actual shipping of the packet. The communication port stays idle until the packet finishes shipping.
By default a port should stay open forever but most hardware will close it down manually.
By default TCP will send a small packet across the network every two hours to keep it open.
Some hardware such as a router or firewall will close it down sooner than this. If a large packet is getting sent across a slow network the communication port can be closed before the packet finishes shipping and the operation fails.

Administrative action is necessary to ensure successful MultiSite operation for ClearCase or ClearQuest hosts that are behind firewalls with this “reset” of seemingly idle TCP sockets feature enabled.

There are two possible approaches for resolving this issue:

1.     One approach is to disable this idle TCP socket reset feature on the firewall.

2.     The other approach is to modify the system wide TCP_KEEPALIVE value for TCP connections so that it is reduced to less than 1 hour.

 

The logic in the shipping_server currently sets the TCP_KEEPALIVE socket option, but the default keepalive interval is set to 2 hours on most operating system TCP implementations in accordance with RFC 1122.

For example, to change the TCP_KEEPALIVE interval on Solaris® hosts, add this command ...

ndd -set /dev/tcp tcp_keepalive_interval 2700000


... to the
/etc/init.d/inetinit file. This will set the TCP_KEEPALIVE value to 45 minutes.

Where the value of 2700000 represents milliseconds and is calculated as follows:
45m * 60s = 2700 * 1000 = 2700000 milliseconds.


This setting tells TCP to send the small packet on a more frequent basis to prevent the port from being closed down.

The reset value for the TCP connections should only be increased to accommodate successful sending of MultiSite packets.

Note: The packet size and rate of speed that data is sent over the WAN should be considered when setting the firewall value.


If the time out for idle sockets cannot be modified to be longer than 2 hours (when using the shipping_server to effect data transfer), you must tune TCP on the sending machine to issue the keepalive packet sooner than 2 hours.

Example:

On Solaris this is accomplished by adding the command "ndd -set /dev/tcp tcp_keepalive_interval 2700000" in the /etc/init.d/inetinit file.


Consult your system administrator or operating system manuals for assistance.

13. How do I - limit the range of ports ClearQuest MultiSite would select to navigate a firewall

ClearQuest uses the ClearCase shipping server in a MultiSite environment. The CLEARCASE_MIN_PORT and CLEARCASE_MAX_PORT environment variables can be modified to limit the range of ports available to the Shipping server.

By setting these system variables on the ClearQuest / ClearCase MultiSite shipping server, the range of ports used by the ClearQuest can be specified for usage through a firewall.

 

The specified range of ports used should be allowed through the firewall, in addition to the albd server process port which defaults to port 371.

Please refer to technote
1207525 for additional information on these variables and the ClearCase MultiSite Shipping Server.

Problems & Issues

14. How do I - resend a previously generated MultiSite packet

To resolve this issue and send the packets again, there are two multiutil tools you can use: chepoch or recoverpacket.
Note: Create backup copies of your databases before making any changes to the database.

The multiutil recoverpacket command is the easier option. This command resets the epoch number matrix so that changes in lost packets are resent. All you have to do is give the date to which you want to recover back. This will change the epoch numbers automatically.
For example, here are the parameters you need to specify for the recoverpacket command:


multiutil recoverpacket -cl CLAN -site BOSTON -fam SAMPL -u admin-p password -since 01-01-2006 LONDON


The multiutil chepoch command changes the epoch estimates for another replica back to a specified epoch. In order to reset the epoch numbers, you first have to see the current numbers. The command multiutil lsepoch will list all the epoch estimates.
Note: You cannot change the epoch numbers themselves since they record the true numbers, i.e. the actual state of the replica. You can change only the estimates of the other replicas.

The following example uses Site A and Site B. Site A sent 10 packets to site B, however for some reason site B only received 9. We need to export again from site A.

lsepoch at site A

lsepoch at site B

site A = 10

site B = 2

site A = 9

site B = 2

estimate of site B

estimate of site A

site A = 10

site B = 2

site A = 9

site B = 2

To resolve the error in this example, at site A, we need to change site A's estimates for site B. Currently site A estimates that on site B, A=10. Actual site B only has A=9. Changing the estimate at site A back to 9 will cause site A to generate the missing packet during the next sync export operation.

How do I – understand the rmreplica does not allow user to re-use the replica name issue

There is an issue where IBM® Rational® ClearQuest® does not allow the re-use of a replica name after it has been deleted.

 

Cause

When user performs an rmreplica of the site and then recreates it, the problem of not being able to allocate ID's appropriately occurs. After allocating the correct next_aux_id for the site, and modifying the available value in ratl_id_blocks and master_id_blocks for the site replica ID at both sites to reflect the change, they still have to problem after a synchronization.

The epoch estimates are being updated for the wrong replica. They have the same site_uuid for both working master site and the replica.

 

Solution

This issue has been identified as a defect in ClearQuest. It is being tracked by its APAR number IC38769 and RATLC00696194. The ClearQuest 2003.06.16 release notes have been updated to include the following statement:

"After removing a replica from a CLAN using the rmreplica command, you cannot re-create a replica using the same name as the replica you removed. New replicas must have a new, unique name."

The 7.0 version of ClearQuest introduced a new command renamesite. The renamesite command changes the database set name stored in the registry.

15. How do I – understand how ClearQuest MultiSite - Stores History Dates in Coordinated Universal Time

Rational ClearQuest software stores history dates for records in the history table of the user database. Changes to objects are recorded by inserting a row in the history table. The history table contains two date/time columns: action_timestamp and expired_timestamp. These time stamps have always been recorded in the local time of the database server, which is sufficient in a single site environment.

However, in a replicated deployment, where database servers are in different time zones, storing time stamps in the local time of the database server can cause actions to appear to have occurred out of order. For example, a defect might appear to be closed before it is opened or assigned before it is submitted. The solution to this problem is to store Rational ClearQuest history time stamps in Coordinated Universal Time (UTC).

Documentation for UTC can be found in the UTC Whitepaper, which is located in the ClearQuest Information Center for 7.0.1

16. How do I – understand why the MultiSite Deactivate example in documentation is incorrect

In the ClearQuest Information Center and the Rational ClearQuest MultiSite Administrators guide, cq_ms_admin.pdf, page 68 Chapter 8, step 7 of the section: "Removing a functioning replica from a clan" incorrectly states:


"If you are deleting the last replica of a family, you must run deactivate at the working master site. At site boston_hub, run this command: multiutil deactivate -clan telecomm -site boston_hub -family MASTR -user susan -password passwd ".


This statement is incorrect. When you run this command as documented you will receive the following error:


multiutil>  deactivate -clan myclan -site boston -family mastr -user admin -password ""

Multiutil: Error: Cannot deactivate MASTR family.


You do not run the deactivate command against the MASTR database. You run the command against the user database using a statement such as:


multiutil> deactivate -clan myclan -site boston -family sampl -user admin -password ""


To verify that the replica has been deactivated you can run the lsreplica command with the -long switch like this:


multiutil> lsreplica -clan myclan -site Boston -family sampl -u admin -p "" -long


This command would return output similar to the following:


Name: BOSTON; Clan: MYCLAN; Family: SAMPL; Host: wmorrissey6; Status: NORMAL, NOT CONNECTED; Description: ; Block Size: 4096; Block Threshold: 1024

Name: ENGLAND; Clan: MYCLAN; Family: SAMPL; Host: wmorrissey6; Status: REMOVED, NOT CONNECTED; Description: de-activated by rmreplica; Block Size: 4096; Block Threshold: 1024

Name: LONDON; Clan: MYCLAN; Family: SAMPL; Host: wmorrissey6; Status: REMOVED, NOT CONNECTED; Description: de-activated by rmreplica; Block Size: 4096; Block Threshold: 1024


The deactivate command must also be used to remove a family. For example, you have Site 1 (the working master), Site 2, and replicated families SAMPL and TRCB, and you want to remove the family SAMPL but still use the family TRCB on both sites. After the family SAMPL is removed from Site 2, you have to run the deactivate command on Site 1 (the working master) for family SAMPL, to get SAMPL removed from the MultiSite environment.

This issue has been identified as a ClearQuest documentation defect.


This website is published "as is". There is no warranty of any kind (express or implied) as to the operation of our site, the accuracy of the information or the services or products referred to on it. All warranties are excluded as far as permitted at law. Neither we nor any third party will be liable for any losses or damage that may result from use of the website or as a consequence of any inaccuracies in, or any omissions from, the information which it contains.