In version 5.0 of the Requirements Management (RM) application, the data is no longer stored on Jazz Team Server (JTS). Rather, data is stored in the RM server. Because of this change in where the data is stored, the steps for the upgrade procedure significantly changed. Compared to the procedure to upgrade to version 4.x, the procedure to upgrade to version 5.0 has more steps.

An RM upgrade script is provided with CLM v5.0 to automate the upgrade when specific conditions are met. A new article Running the RM Upgrade Script for version 5.0 has been published to guide you through the RM Upgrade script to help you understand what will take place by running the RM The article also provides details about where particular files must be located and how to specify command line parameters in order for the RM upgrade script to be successful.

Note: As noted in the article, the RM upgrade script can only be used if the following conditions are met. Check the Interactive Upgrade Guide if you have questions as to whether or not this script can be used in your environment.

Jazz Team Server (JTS) has been successfully upgraded to version 5.0 AND

All applications are installed on the same server OR applications are distributed and you can mounts shared directories between servers AND

Your server is not running on a double-byte character set Windows server

Note: The RM upgrade script does not provide the ability to specify a parameter file.

Refer to the New and Noteworthy and Release Notes sections of the DOORS Next Generation 5.0 download page for information about other changes that were introduced in Rational DOORS Next Generation 5.0.

Yes, it's theIndependence Dayholiday here in the US, and your faithful blog authors (at least those of us based in the U.S.) are off enjoying a long holiday weekend, complete with parades, fireworks, outdoor concerts, and backyard barbecues.

Here atNotes from Rational Support, as always, we welcome your comments and feedback here on the blog, throughtwitter, GooglePlus, tumblr, or on ourFacebook posts.

Engineers from Rational Support have been hard at work producing white papers that help you navigate through some of the more advanced activities for Rational products. Here are some of the latest papers published.

Title: Rational license migration from floating to tokenAbtract: The primary goal of this paper is to familiarize the key stakeholders involved in a token transition project. The document provides a detailed step by step process involved in a transition. The steps described within this document is a collateral of knowledge gained from various token deployments undertaken by the IBM Rational Licensing Team.Authors: Indraneel Paul, Edwin Stalin, and Krishna Kumar

Title: Configuring Rational DOORS Help on Citrix environmentAbtract: Rational DOORS uses an Eclipse based help system that can be configured in different modes. Each Rational DOORS client that is installed on a user system can be independently configured in any one of the HELP modes. However, when Rational DOORS is published through a supported terminal or presentation server, a DOORS Administrator can choose to configure common help modes for all users. This document touches upon each HELP mode in the context of a terminal / presentation server. Citrix Xenapp 6.5 is used for testing the scenarios that are presented in this document.Author: Pallavi Parakh

Title: Differences between Rational Rhapsody 8.0 Statecharts and UML 2.4.1 Behavior State MachineAbtract: OMG UML and IBM Rational Rhapsody have been evolving in parallel, and some differences were created and expanded over time. Not all graphical notations that are defined in UML specification are supported by Rhapsody. There are certain patterns of transitions you cannot draw due to restrictions imposed deliberately, but not necessarily limited by UML specification. Some of UML features such as deferred event and do-activity are not natively supported today. This document covers such gaps that are found between UML specification and Rhapsody implementation, aiming to help you design statechart more effectively and enable easier interchange of statcharts among UML-based modeling tools.Authors: Shinji Kanai and Moria Abadi

Thank you to Indraneel, Edwin, Krishna, Pallavi, Shinji and Moria for their contributions!

Rational Support encountered a case for IBM Rational Team Concert (RTC) where 400+ custom attributes in a project needed to be deleted. These attributes were removed from the presentation and from "Types and Attributes" in the process configuration, but they still show up in the Query Editor.

In this situation, how can the custom attributes be deleted permanently so they do not show up in the Query Editor or anywhere else? Unfortunately, there is not a way to permanently delete custom attributes from a RTC repository. This is applicable at least until RTC 4.0.6 versions.

There is a technote that has the details on this and the work around that you can use using the Eclipse client:

One of the options available is to archive the custom attributes and not include these when querying. However, in this example there was a request for a workaround for not being able to delete custom attributes. Again, the environment in this example had over 400 attributes to delete.

One of the workarounds being considered by the client was to create a duplicate project without the custom attributes. The client wanted to know if they can create a RTC project identical to an existing project with the same members, work items and work flows, but without the custom attributes. Additionally, they were not keen to create the project manually and having to recreate the work item types and work flows. Then they could export the existing work items and import them into the new project.

As an alternative, here are some possible steps you can take instead of deleting the custom attributes. However, I strongly recommend that these steps be tested first on a test set-up to verify if this meets the requirement behavior before trying this on a production system.

Export the existing process template from the initial project area.

Import it on a test server.

Modify the process template by removing the custom attributes and as well as removing these from the work item editor in the test server.

Save the process template.

Now create a new project area based on this modified process template.

From the initial project area, export the work items without the custom attributes and import them in this new project area, which is created in step 5.

This is an alternative which should retain the work flows, work items. However, this would not retain the work item history.