This file contains descriptions of noteworthy problems in version 2003.06.00 of Rational ClearQuest MultiSite.
The following are the known problems in this release of MultiSite.
#RAMBU00016831 describe and chmaster commands do not find entity if the entity display name has a colon
#RAMBU00017072 After import, there is no indication that a user database upgrade is required
#RAMBU00017107 ClearQuest uninstall followed by reinstall deletes database set information
#RAMBU00018832 syncreplica –import leaves behind temporary attachment files
#RAMBU00019099 Problems with subscription information for nonreplicated databases
#RAMBU00019299 Problems editing reports and queries with the Web client when duplicate names exist
#RAMBU00020796 Errors when changing mastership of ambiguous users
#RAMBU00021115 ClearQuest Designer does not tell you to upgrade the user database when user or group mastership is changed
#RAMBU00021601 Times in syncreplica –import errors are not displayed in local time
#RAMBU00021609 shipping server does not return expired packets to sending host
#RAMBU00021612 Stopping the mkreplica –export process locks databases
#RAMBU00022266 mkreplica –import fails with “Unknown exception” error messages
#RAMBU00022275 A failed activate command creates part of a database set and prevents future activation
#RAMBU00033529 Unable to modify a mastered stateless record when the record is ambiguous
#RAMBU00036370 Changing a package query's mastership with the GUI may change its package ownership
#RAMBU00036611 Changing mastership of a package query results in duplication of the query when the package is upgraded
#RAMBU00036613 The restorereplica command fails if you try to restore a replica that is dependent on restoration packets from a removed replica
#RAMBU00036844 After removing a replica, you cannot re-create the replica using the same name
#RAMBU00036959 ClearQuest COM interface does not detect when it corrupts new field values
#RAMBU00037163 syncreplica –import fails if the exporter and importer use different operating system code pages
#RAMBU00037164 restorereplica expects only one packet from each donor site
#RAMBU00045796 syncreplica doesn't put packets in root of drive
#RAMBU00046027 syncreplica –export failure with non-ASCII character in the database name
#RAMBU00046132 Naming conflicts for queries and reports are not handled correctly on the Web client
#RAMBU00050626 Missing or ambiguous syncreplica error messages when disk space has run out
#RAMBU00055249 rmreplica –dbset does not remove the last replica in a MultiSite clan
#RATLC00445979 ClearQuest “History” and “Latest History” are not always correct
#RATLC00690481 mkreplica –import may fail when invoked on a directory that contains multiple packets
#RATLC00693521 ClearCase, ClearQuest, and Rational Shipping Server Incompatibility
If you use a colon as part of the display name of an entity or a workspace object, chmaster and describe fail with the following error:
This problem does not happen with users and user groups because a colon is not a valid character in a user or group name.After importing an update packet that contains user administration changes for the user database or schema repository, no message is displayed to inform the user that a database upgrade is required. If the user database is not upgraded at the importing site, the database will be out of sync with the schema repository.
Workaround: To keep the user databases and schema repository synchronized, you must upgrade your user databases after importing an update packet that contains user administration changes.
The ClearQuest MultiSite command line interface, multiutil, uses a unique database set name to access database replicas. When ClearQuest is uninstalled from a machine, the database set information about that machine is removed. When you reinstall ClearQuest the database set information must be re-created. On machines where the multiutil command line runs to complete the ClearQuest reinstall, do the following:
In a command window, set the database set environment variable:
set BB_TEST_DBSET_NAME=CQMS.CLAN_NAME.SITE_NAME
The CLAN_NAME and SITE_NAME are specific to your ClearQuest MultiSite installation.
From the same command window, start the ClearQuest Maintenance Tool:
cqdbsetup.exe
You must run this command in the context of the environment variable set in Step 1.
In the ClearQuest Maintenance Tool, select Connect to Existing Schema Repository and provide the connection information for the schema repository for this site. The connection information is now registered under the specified database set name.
When a site receives an oplog that it has already processed, it abandons the operation and does not delete any attachments that came with the oplog. The temp area fills up quickly with abandoned attachment files. It is safe to remove these files on a regular basis.
Several problems occur when you subscribe a user to a nonreplicated database whose schema repository is replicated. For example, you have a schema repository with databases DB1 and DB2 at site A. At site B, you create a replica of the schema repository and database DB1, but you do not replicate DB2. At site A, you create a new user and subscribe the user to both DB1 and DB2. As expected, the user can log in to DB1 at both sites and can log in to DB2 at site A. However, the following problems occur:
Administrators can view and modify subscription information for the new user at site A, but cannot view or modify the subscription information at site B.
If you replicate DB2, the new user is not automatically subscribed to it at site B. However, the subscription information reports that the user was subscribed. To correct the subscription information and subscribe the user, an administrator must unsubscribe and then resubscribe the user.
If you have two queries or records with the same name, the following problems can occur with the Web client:
When you attempt to save changes that you made to an existing report or query (any report or query, not only the reports or queries with duplicate names), the Web client overwrites another query or record with the new data.
When you save changes that you made to a duplicate name report that is locally mastered, the Web client creates a new report with a "1" appended to the original name.
When you attempt to save changes that you made to a duplicate name report that is not mastered by the local replica, the Web client displays the following message:
However, your changes are not saved because the local replica does not have mastership of the report.If there are two users with the same login name (ambiguous users) you are prevented from changing the mastership of either one of the users. The errors you see depend on the tool you use to change the mastership:
If you use the User Administration Tool, you see an error similar to the following:
If you use the UNIX or Windows client, you see an error that warns you about creating a duplicate user name and violating data integrity.
If you use the Web client, you do not see an error message, but the mastership change does not succeed.
Workaround: Change the name of both users so that they are unique.
When you change user or group mastership with the ClearQuest Designer, the tool does not tell you that you need to use the User Administration Tool at the new master site to upgrade the user database. You must upgrade the user database in order for the mastership change to be recognized at the new master site.
When you use the multiutil chmaster command to change mastership, the command gives instructions about upgrading the user database.
When an update packet is lost during synchronization, or some packets are received out of order, you may see the following message when you run syncreplica –import:
The date and time in this message (2001-06-06 16:19:02) is given in GMT instead of local time. All other multitool commands display local times in error messages.The shipping server does not return packets to the originating host after a shipping order expires. Administrators at the original sending host do not receive e-mail notification that the packets were not delivered.
Comment: CMBU00047501 - Corresponding ClearCase MultiSite defect
If you press CTRL+C during the mkreplica –export process, the databases remain locked.
Workaround: Use the installutil commands, unlockschemarepo and unlockuserdb, to unlock the schema repository and user databases. For command syntax, see the Administrator's Guide for Rational ClearQuest.
The –infamily option of the lsreplica command is case-sensitive. The command does not work if you specify the family name in the wrong case.
When you run the mkreplica –import command, it may fail with an Unknown exception error message. This message may mean one of the following things:
Workaround: If you receive an ambiguous error message, call Rational Customer Support.
Use the installutil dropdbset command to remove the incomplete database set. For example, to remove a database set named CQMS.TELECOMM.BOSTON, run the following command:
installutil dropdbset CQMS.TELECOMM.BOSTON
*********************************************************
Starting test dropdbset
*********************************************************
*********************************************************
Exit code 0 for test dropdbset
*********************************************************
In a MultiSite environment, you can have two stateless records with the same name at two sites (ambiguous records). If, at either site, you try to modify (but not rename) the ambiguous record that is mastered by the local replica you see this error:
ERROR! There is already a Email_Rule named email-rule-name. This would cause duplicate entries in the database. Make sure fields:
Name
contain unique values. Please note that leading or trailing spaces are not considered as part of the value.
Workaround: Rename one of the ambiguous records and synchronize all replicas.
Workaround: Use the multiutil –chmaster command to change the mastership of package query, which ensures that the query retains its original package ownership.
If you change the mastership of a package query or change the working master, a duplicate of the query is created when you upgrade the package. If you create a duplicate query this way, follow these steps to remove the extra query:
Verify that all package queries are mastered by the working master site. Change mastership if necessary, using the multiutil –chmaster command. (Do not use the GUI to change mastership of package queries. For more information, see #RAMBU00036370 Changing a package query's mastership with the GUI may change its package ownership.)
If you do not want to change the mastership of all package queries to the working master, you can also delete all package queries, at whatever site they may be mastered, and skip to Step 3.
At the working master site, manually install package queries using the packageutil installqueries command.
If you remove a replica, and then attempt to restore another replica that depends on packets from the deleted replica, the restorereplica command fails.
Workaround: To use the restorereplica command in this situation, you must do one of the following:
Specify only the active replicas the first time you run restorereplica. Run the lsreplica command to display a list of active replicas.
Run the initial restorereplica command (specifying all active and deactivated replicas), wait for responses from all of the active replicas (run the lsreplica command to display the active replicas along with the status of their response), and then run the restorereplica –completed command to force completion of the restore operation.
After you remove a replica from a clan, there is no way to re-create the replica with the same name.
Workaround: You must create a new site with a different name to use in its place.
For fields on an entity (for example, a Defect or ChangeRequest) the incoming strings are checked for code page compatability. Specifically, only the command entity.SetFieldValue checks that the incoming UNICODE strings can be translated to the ClearQuest data code page All other COM API methods that take a string as a parameter do not check that the string is valid in the ClearQuest data code page.
The command to set multiple fields at once, entity.SetFieldValues, is not code page protected.
The syncreplica –import command fails if the exporter and importer do not use the same operating system code page, even if the ClearQuest data code page is set to 20127 (ASCII). The command fails with an error similar to the following:
Multiutil: Error: The code page of the exporter or source schema repository is incompatible with the system's current code page. Source schema repository code page (20127 (US-ASCII)). Exporter code page (1252 (ANSI - Latin I)). Current system code page (932 (ANSI/OEM - Japanese Shift-JIS)). Multiutil: Warning: No packet imported - the specified file or directory does not consist of any eligible packet.
To successfully synchronize replicas, all synchronization servers must run the same operating system code page.
The restorereplica command expects only one packet from each site in a clan. If the –limit option is used with restorereplica and all the requested data cannot fit within the specified size limit, the site being restored can be unlocked prematurely. Do not use the –limit option when generating packets for a site under restoration.
When you use the syncreplica –export –out command, you cannot specify the root directory of a drive as a location for the output packet file.
The syncreplica –export command fails if you change the data code page of a user database to 20127 (ASCII), and the database name contains non-ASCII characters.
If two queries or reports with the same name are created at different replicas, only the query or report mastered by the current replica can be accessed from the Web client. If you try to access the duplicate report or query that is not mastered by your current replica, you see the following error:
This workspace item has the same name as another one. Please correct the problem by renaming the items that have the same name.
Both queries or reports can be accessed with the UNIX or Windows clients without receiving an error message.
When you run syncreplica –export, it creates an update packet as well as a temporary packet that is removed when the command completes. If you have limited disk space, these packets can fill up the disk and stop the syncreplica –export process from creating a complete packet.
If you attempt to synchronize replicas when there is not enough disk space:
Before you run syncreplica –export, make sure that you have enough disk space for the update packet and the temporary packet file that syncreplica creates.
When you remove all replicas in a clan, you should be able to use the rmreplica –dbset command to return the schema repository to a non-MultiSite state. However, even after running the rmreplica –dbset command, the schema repository remains activated as a MultiSite schema repository.
Workaround: To return a MultiSite schema repository to a non-MultiSite state, you must do the following things:
For instructions to perform these tasks, see the Administrator's Guide for Rational ClearQuest.When you use MultiSite, the history of ClearQuest records reported in SoDA and ProjectConsole do not always have correct Action_timestamp values. The Action_timestamp values are recorded in the database using times local to the site of the database. If the mastership of a record changes from a replica in a time zone where one local time is earlier, it is possible for the next Action_timestamp value to be earlier than the previous one. Because the history records are sorted by Action_timestamp values, in these cases the order of the history records will not be the order in which they actually occurred.
When you use the mkreplica –export –fship command to create a replica of a site with two user databases or families, multiple replica creation packets are delivered to the storage bay. Using mkreplica –import to import the first packet is successful, but import of the remaining packets fails.
Workaround: When you run mkreplica –import, specify the pathname of all replica creation packets.
RATLC00700733–CQ NR New
There is no UNIX platform support for Rational Shipping Server for ClearQuest MultiSite. The Rational Shipping Server is only supported on Windows server operating systems.
Rational recommends that you avoid configuring any one host to run the Rational Shipping Server for both ClearCase and ClearQuest, because uninstalling 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 ClearCase MultiSite and ClearQuest with the Rational Shipping Server on the same Windows host, ensure that you do the following:
Administrators must verify that site configuration files for typical host systems do not specify installation of the Rational Shipping Server. Any attempt to install ClearCase on a Windows host where ClearQuest and the Rational Shipping Server are already installed will fail.
Table 1 lists significant problems in previous MultiSite releases that are fixed in this release.