Upgrade Alert! License package changes affect some upgrade scenarios


There was a change made in how the various CLM app-specific functional Client Access licenses (CAL) are packaged in CLM v4.0.1 which has caused a problem for staged upgrades to v4.0.1 or greater from versions 3.0.1.x or 4.0 in distributed environments.   A staged upgrade is the kind that we have always recommended and it means if you have multiple CLM applications, you should upgrade them one at a time.  The issue along with the workaround is described in detail in this workitem:  Incorrect documentation for upgrading JTS and apps in a staged fashion when going from pre-4.0.1 to post 4.0.1 CLM release (251460)

Basically, there are functional app-specific CALs such as the CCM Data Collector, QM Data Collector, RQM Connector, Build System, CQ Synch, and CC Synch that used to be packaged with the Required Base License Keys Including Trials package that was installed by Installation Manager along with the JTS and the CLM server packages prior to v4.0.1.  In version 4.0.1, a change was made to rename this license package as well as to move these app-specific functional CALs to be contributed by their respective CLM server applications.  For example, the CCM Data Collector, CQ Synch, Build System and CC Synch CALs are now being contributed only when the CCM (4.0.1 or greater) server package is installed.  Thus, let’s say that you are planning an upgrade from v3.0.1.4 to CLM v4.0.1 and have a distributed CLM deployment with a JTS, CCM and a QM application.  You start by staging an upgrade of just the JTS and CCM applications.  So, you install the JTS and CCM 4.0.1 install in their respective locations so that you can perform a side by side upgrade.  In v4.0.1, the license package is called Trial Keys for Collaborative Lifecycle Management Products.  It only contains the Trial licenses.  The other licenses needed are now contributed by the applications themselves.  Thus, if you upgrade only JTS and CCM to v4.01 and leave QM at v3.0.1.4, you will have some license assignments that refer to licenses that no longer exist such as the QM Data Collector or RQM Connector.  This is because QM is still at v3.0.1.4 and these licenses will not be provisioned until QM is upgraded to v4.0.1.  If you upgrade all the apps at once, this is not an issue.  This is only an issue for staged upgrades.

What is being done about this problem?

A zipfile containing all of the 4.0.x functional CALs is being made available via workitem 251460 above that can be installed via the JTS Admin web UI after the JTS is upgraded.  This will allow these functional CALs to be persisted in the database.  At the time you subsequently upgrade any of the apps such as CCM, QM or RM, all the functional CALs associated with the application would need to be deleted.  This is necessary so that the new CALs contributed by the upgraded app will take effect rather than the ones persisted in the database.

Why do we need to install these 4.0.x functional CALs in the first place?

These functional CALs are assigned to functional users.  Since they are now contributed by the applications, once the JTS is upgraded, the older functional CALs are removed so you end up with functional user CAL assignments to licenses that do not exist.  This causes problems with the operation of the non-upgraded applications.

Why do we need to delete these 4.0.x functional CALs prior to upgrading a particular application?

If they are not deleted, then these functional CALs persisted in the database repository will take precedence over any CALs contributed by the upgraded app.  This is not the state we want to have.


RDz – RTC Compatibility

In this post, I want to outline the RDz considerations to keep in mind when upgrading RTC from 3.x to 4.0.

The information below is applicable to the following releases:

  • RTC 3.0, 3.0.1, 3.0.1.x, 4.0
  • RDz: 8.0.3.x, 8.5



Eclipse client:

This is the Eclipse based client that can be shell shared with the RDz Eclipse client. For the two products to interact they need to shell share.


This is the server piece of the CLM product (in which RTC is an application along with RQM and RRC). The server can run on various different platforms and the clients connect to it via a web browser or an eclipse IDE.

Build Toolkit:

This is part of the RTC product that is installed on the platforms that code needs to be built on.  In the case of mainframe development, it is installed on the zOS system.


Eclipse client:

This is the Eclipse based client that can be shell shared with the RTC Eclipse client. Obviously for the two products to interact they need to shell share.

RDz server side code:

This is code that must be installed onto the z/OS system so that the RDz client can talk to it. There are various parts to this such as the RSE (Remote System Explorer) that enables the RDz client to interact with the z/OS file system. There is also the Job Monitor that allows RDz to get notification on jobs running on the z/OS system. This enables a job to be submitted via the RDz Eclipse client and the Eclipse client being able to monitor the job and report back its status.

RTC/RDz Integration – What is it exactly?

The integration is achieved by first installing the two clients using shell sharing. Shell sharing means that they can coexist but there is no specific targeted integration yet between the two products. One can use the RTC functionality and the RDz functionality in the same client but there is no specialized integration going on. What is available from RTC 2.0 and onwards is some meaningful integration between the two clients. This is provided via an installable feature that is shipped with the RDz product. It is the ‘glue’ that allows the RDz Eclipse client and the RTC client to become aware of each other and work together.

With RDz 8.5, there is a change with the API that RTC uses to communicate with RDz (i.e. the API changed). Thus, there are two RTC/RDz Integration features shipped with RDz 8.5. One allows RTC 4.0 to talk with RDz 8.5 and the second one allows RTC 3.x to talk with RDz 8.5. Based on the version of the RTC client, pick the correct integration feature to install in your environment.

Now, what integrates with what exactly?


The only combination of clients that will NOT work is RTC 4.0 + RDz 8.0.3.x. Another way to say this is that RTC 4.0 pre-req’s RDz 8.5 if you want to use the integration feature. All other combinations work and have been tested either by RTC test team or by the RDz test team.

RDz Server side code (mainframe)

  • The RSE shipped with RDz 8.0.3.x will work with RTC 3.x and 4.x
  • The RSE shipped with RDz 8.5 will work with RTC 4.x

RTC server compatibility

There is N-1 client compatibility.  Thus, an RTC 3.x client will work with an RTC 4.0 server and obviously a RTC 4.0 client will not work with a RTC 3.x server

Build Toolkit

We recommend the following combinations of client and build tool kit combinations when the server has been upgraded to RTC 4.0

  • RDz 8.0.3.x client + RTC 3.x client would use RSE + build tool kit 3.x
  • RDz 8.5 client + RTC 4.x client would use RSE + build tool kit 4.x

I’m upgrading my RTC environment(clients and server) to 4.0, what do I have to upgrade?

On the client side, you will need to upgrade the RDz clients from 8.0.3 to 8.5 and use the RTC/RDz integration feature provided shipped with RDz 8.5.

On the server side, specifically the RSE, the 4.0 RTC / RDz 8.5 client integration will work with the RDz 8.0.3.x RSE. Naturally, any server-side dependent features for 8.5 will not work, so the user is restricted to 8.0.3 functionality for anything that is related to server side function.

Additionally, on the server side, there may be build toolkits installed. Any 3.x RTC client should continue to use a 3.x build toolkit.  Any 4.0 RTC client should use a 4.0 build tool kit.

CLM 2012 is coming. Are you ready?

Well, I know it’s been a while since my last post.  Sorry, but it sure has been a busy year for me as a Jazz Jumpstart team member.  Last year at this time, I was busy testing the upgrade to CLM 2011 and helping our User Assistance team put out the best documentation possible.  The Jazz Jumpstart team also released a great workshop to help folks learn how to upgrade to CLM 2011:  https://jazz.net/library/article/662

So, what am I up to now?  I’m busy testing and helping to document the upgrade to CLM 2012, of course.  I started thinking that there are things CLM customers could be doing now to get ready to upgrade to CLM 2012.  Why not blog about it?  So here goes…..

Review the CLM 2012 System Requirements


Review the upgrade process

The Jazz.net development wiki contains some drafts of the upgrade process.  Review it to start getting familiar with the process.  Remember that this is all pre-release and subject to change.  The official upgrade process will be in the 4.0 infocenter.


Start preparing a test environment for upgrade testing

This is still a good idea even though the upgrade process this year is much easier.  Here is a way to get started:  Staging a test environment for the upgrade process

Once you have a test environment set up, try it out the process with one of the 4.0 release candidates:  Download 4.0 RC3

Configure a data warehouse if you haven’t already

When you first upgraded to CLM 2011, you may have skipped configuring a DW.  Plan to configure a DW so that you can begin taking advantage of the CLM reporting features.  And, when you upgrade to CLM 2012, you will be able to avoid running JTS setup altogether.  Read this topic for assistance:  Configuring the DW after running JTS setup

Upgrade to the latest fixpack

Do some research on the IBM support portal pr the Jazz.net website and figure out if you should upgrade to the latest fixpack of the CLM applications you are running in your deployment.  The latest fixpack is v3.0.1.3 for RTC, RQM and RRC.  It’s easy to upgrade to the latest fixpack of CLM 2011.   Read this topic for assistance:  Upgrading to version 3.0.1 fixpack releases