I have to move 3 RTC and 1 RQM servers from one server to another server
with a different server name.

I know that there are issues with trying this with RTC 3.0, but can I do
this with RTC 1.x and RTC 2.x? Is this possible for RQM 2.x?

Tony

What you mean, 'I have to move' , If you do export and import operation via repotools, there is no need to worry about server name for any versions of RTC and RQM.

"muralindia" <muralindia> wrote in message
news:iq00k3$kt8$1@bluesdev1.torolab.ibm.com...

Tonywrote:
I have to move 3 RTC and 1 RQM servers from one server to another
server
with a different server name.

I know that there are issues with trying this with RTC 3.0, but can
I do
this with RTC 1.x and RTC 2.x? Is this possible for RQM 2.x?

Tony

What you mean, 'I have to move' , If you do export and import
operation via repotools, there is no need to worry about server name
for any versions of RTC and RQM.

That is not exactly true

If you look at the documentation for RTC v3 you will see something like
this:

From IBM/Rational Documentation:

?

Applications and the Jazz Team Server generate absolute URIs to resources
that are used for the following purposes: stored artifacts, mail
notifications, feeds, for copying to the system clipboard, web access, and
for stable resource identification across all applications. These URIs are
rooted by a "Public URI" that is declared for the application or Jazz Team
Server.

It is important that you choose a public URI that is fully qualified, likely
to remain stable over time, and accessible from anywhere in the network
where users need to connect. The Public URI must be configured during setup
of the Jazz Team Server and the applications, and can be set, validated, and
tested in the Jazz Team Server Setup Wizard. After the resources have been
stored in the repository, the public URI cannot be changed. However, a URI
that is based on a stable hostname can be rerouted through DNS.

So it's not that simple....You would have the same issues with all of them. The public URI cannot be changed with your stored artifacts. After exporting and importing on the new server, your links would be broken.

The documentation is correct.
Many (and in some cases, most) of the information is brought over just
fine, but some of the references are in the form of URL's that continue
to refer back to the original location of the server.
Making this move possible is work item 127009.
Please feel free to add a comment to indicate your interest/support.

Cheers,
Geoff

On 5/6/2011 6:59 AM, Tony wrote:

"muralindia"<muralindia> wrote in message
news:iq00k3$kt8$1@bluesdev1.torolab.ibm.com...
Tonywrote:
I have to move 3 RTC and 1 RQM servers from one server to another
server
with a different server name.

I know that there are issues with trying this with RTC 3.0, but can
I do
this with RTC 1.x and RTC 2.x? Is this possible for RQM 2.x?

Tony

What you mean, 'I have to move' , If you do export and import
operation via repotools, there is no need to worry about server name
for any versions of RTC and RQM.


That is not exactly true

If you look at the documentation for RTC v3 you will see something like
this:

From IBM/Rational Documentation:

?

Applications and the Jazz Team Server generate absolute URIs to resources
that are used for the following purposes: stored artifacts, mail
notifications, feeds, for copying to the system clipboard, web access, and
for stable resource identification across all applications. These URIs are
rooted by a "Public URI" that is declared for the application or Jazz Team
Server.

It is important that you choose a public URI that is fully qualified, likely
to remain stable over time, and accessible from anywhere in the network
where users need to connect. The Public URI must be configured during setup
of the Jazz Team Server and the applications, and can be set, validated, and
tested in the Jazz Team Server Setup Wizard. After the resources have been
stored in the repository, the public URI cannot be changed. However, a URI
that is based on a stable hostname can be rerouted through DNS.

So it's not that simple....