Select the options that apply to your environment to generate a customized guide to upgrade from a previous version (starting from 6.x) to version .
Upgrading from a version 5 release to version : Upgrading from a version 5
release to version is a two-step process. You must first upgrade your server to the latest
fix pack of the version 6 release, start the server, ensure that the version 6 upgrade was successful, and then upgrade
to version .
For instructions on upgrading from a version 5 release to the latest version 6 release,
see the latest version 6 documentation.
upgrade: For information about upgrading the applications
on , see Planning to upgrade on
.
Attention: It is recommended to apply the latest interim fix to your current installation before continuing with the upgrade process. This ensures a smooth transition between the two versions.
Attention: After you have made your selections, if you want to change the product version, it is recommended to refresh the browser and start with your selections again to generate the content.
Note: You can upgrade any applications in your environment; however, clustering is only supported for the and applications in this release.
Note: After you successfully upgrade to version , retain the upgrade logs for a year. IBM Support might need these logs if you open a support case.
The complete instructions to upgrade your () applications to version are generated based on the selections and inputs that you provided on the previous page.
Deployment topology |
|
Applications to upgrade |
|
Custom context root |
|
Previous installation path |
|
New installation path |
|
Upgrade method |
|
Previous product version |
|
Operating system |
|
Application server |
|
Database server |
|
Configured data warehouse |
|
Installing Jazz Authorization Server |
|
If you have installed the application, it must be upgraded after and before any other applications.
For larger repositories (greater than 100K artifacts), the default heap size in the repotools-app (where app is the application that you are upgrading) is too small. You must increase the heap size to 16 GB (up to a maximum of 24 GB) to avoid issues during the upgrade. Increasing the heap size, also improves the upgrade performance by up to 20% for smaller repositories.
To increase the heap size, set the REPOTOOLS_MX_SIZE environment variable to increase the maximum memory limit for repotools command. The value is in megabytes. The default is 1500.
Use this planning checklist to ensure that you are ready to upgrade.
Planning task | More information | |
---|---|---|
Use the software product compatibility reports: On this page, you can search and generate reports for a specific product. The information includes prerequisites, product translation into a specific language, end of service, server virtualization environments, and more. | Software product compatibility reports | |
Gather required information: Before starting the upgrade process, you must gather and record specific data that is required during the upgrade process, such as URLs, user IDs and passwords, database locations, name of databases installed, and so on. | ||
Verify that your hardware and software meet the minimum system requirements: New requirements exist for version , and a few older versions might be deprecated. To learn about the new requirements and to see whether your system meets the minimum requirements, click the System requirements link. | System requirements | |
Get the product installation media: For a local repository download, you need approximately 5 GB of hard drive space to download and extract your product installation media. | You can download the server installation files from jazz.net or Passport Advantage. | |
Review an upgrade topology example. | ||
Synchronize the clocks on all servers: In a distributed environment, ensure that the clocks on all servers are synchronized by using the Network Time Protocol (NTP). | For more information about NTP, visit ntp.org | |
Understand the upgrade process: Learn about the upgrade process and how the upgrade might affect your deployment. | Understanding the deployment and upgrade process | |
Plan for your applications to be unavailable: Your applications will be unavailable for a brief period while you back up everything and update your applications to version . All of the applications that are connected to will be offline while is offline. Be sure to provide time to completely back up your existing applications. | ||
Meet your database prerequisites:
IBM Db2i® database is preconfigured on your IBM® i system.
Creat a backup of your IBM Db2 for z/OS® database before the upgrade.
Restriction: Because of a defect in Oracle JDBC driver 12.1.0.2.0, this version of the driver cannot be used. For details, see repotools -createTables command fails with ORA-01000 on Oracle 12 on the IBM Support portal page.
Important: Before you start the Quality Management - application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours. Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows: DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL EXEC sp_updatestats EXEC DBMS_STATS.GATHER_DATABASE_STATS |
||
Learn about licensing: Click the link to learn about licenses in this release.
Important: You need to obtain new license for . See the "Obtain licenses" step for details. |
Managing licensing | |
Check the browser compatibility:
|
||
Check the client and server compatibility:
must be at the same level as or newer than the applications that are registered with it, but the applications cannot have a newer version than . |
For more information, see Client and server version compatibility | |
Check your Java Virtual Machine options: Make sure that the Java Virtual Machine has the appropriate heap size setting. If you are installing all applications on one server for trial or demo, ensure you have enough memory installed. The JVM settings for the server can be adjusted in the server.startup file.
For
only: The -Xmn value should be 33% of the -Xmx value. For example, if
the -Xmx size is 4gb, the -Xmn should be 1365m. Before you upgrade the application, make sure you verify the Jena index. Validate the indexes using the repotool_rm verifyJFSIndexes command. If the Index verification reports an error, rebuild the Jena indexes using the repotools-rm -reindex all command. |
|
Note: Do not copy the text indices. Starting in version 6.0.6.1, the Apache Lucene full-text search engine was upgraded to a more recent version. As a result, all existing full-text search indexes that were created in 6.0.6 or earlier must be rebuilt. For details, see this workaround article.
Engineering Lifecycle Management version 7.0.0 - 7.0.2 supports two application servers; WebSphere® Application Server and WebSphere Liberty. The support of WebSphere Application Server is no longer available in ELM starting with version 7.0.3. Due to this change, you must migrate ELM on WebSphere Application Server to WebSphere Liberty. You must migrate from WebSphere Application Server to WebSphere Liberty before you upgrade to ELM version 7.0.3
Download and install a new instance of ELM in parallel with your existing installation. Ensure to select the option to install WebSphere Liberty Profile. This installation must be the same version as your current application version. The new installation deploys WebSphere Liberty Profile with most of the required settings preconfigured to run ELM applications. It is recommended that each application run on its own server or at least its own WebSphere Liberty Profile (for process isolation). Each profile has its own JVM resources. For detailed installation instruction, see Interactive Installation Guide.
You must stop the WebSphere Application Server before starting the WebSphere Liberty instance.
The task does not include component-specific WebSphere Application Server to WebSphere Liberty migration steps because there are parts of WebSphere Application Server configurations that do not exist or are not needed in WebSphere Liberty.
If you have your server setup as a service, ensure to disable automatic startup. Once the migration from WebSphere Application Server to Liberty completes, you might want to remove the application server service. See instruction in step 4 from here.
Although the embedded Liberty Profile comes with most of the required settings to run the ELM applications, there are the following settings that need to be configured manually:
If your ELM WebSphere Application Server installation is configured to use LDAP as the user registry, perform the following steps:
User Registry
If the ELM WebSphere Application Server installation is configured to use the default internal user registry, you must migrate the user records to WebSphere Liberty. See, Configuring a basic user registry for Liberty.
Certificate
(For Linux)
openssl s_client -connect myelm.com:9443
(For Windows)
Sample certificate:
-----BEGIN CERTIFICATE----- MIIDGTCCAgGgAwIBAgIEFInHnjANBgkqhkiG9w0BAQsFADA9MQswCQYDVQQGEwJ1 czEMMAoGA1UEChMDaWJtMQwwCgYDVQQLEwNjbG0xEjAQBgNVBAMTCWxvY2FsaG9z dDAeFw0xNzA1MTMxMDA5MzdaFw0xODA1MTMxMDA5MzdaMD0xCzAJBgNVBAYTAnVz MQwwCgYDVQQKEwNpYm0xDDAKBgNVBAsTA2NsbTESMBAGA1UEAxMJbG9jYWxob3N0 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl5hSpIR+gmyX8t8Cei02 b9GilUqkdfpWZ5kkJaRmJraLKdPlLMPhEEuIfYEb2cKl3livGMVUfZkxgXLNL7rN UOemBaDb882R66sAJ1MZOYAQ976QGRY59hnGiXcX2d7KndCqXmtF7qw6BPS6R7nX 6nog4P7tMjV1XFY6N6aN5OL6URBaPwf+7EDWPIF7vVlSDM6CFOAWHqt8HjyeGMPO Rcnmwg21+NhcUwT467mneEWyavgevdNcfRLm9FOjdwRGZnCnqhcjDKkd9yRyjI8h QS2IFPRQVWLPVRQJxDBKBU66k7xhv68bpW4sdkVni26UPzoxQrXNVjETGFxWxfaJ QQIDAQABoyEwHzAdBgNVHQ4EFgQUdEkGyXMjCHunNJi3aHAxdIzpYn4wDQYJKoZI hvcNAQELBQADggEBAI+A7EffStJJC8+wKbulLaesqOED1eml9JY6kqL7ltMI0HEG WRGbYNK0htHmQtzOaHM8gAHd5X5RxHZhOhbaTQ+CH2C4b0MJ+gl9hJGIvt28yiW2 tS4s/Dt1IJ8Cy7/Xz84YJ1VPn4oFy36lJTGgSM+Bg6aItbbx9vNOflDf8C6tyZbg ujMxF2o6BBeKCdBM+Aft164l2uFmVBGIgYQv2aWBNTmxirr72mZnLgo8vGUqc/nA 1T/CJIz8dq6byclfiOjCBkqDr4XlcXtbD6yjdlRqTusiJ17iZvlNPpoYoGGjqS9z JhKmsi2mxWzz7a5ZgsdiK6u+1sn/55MWAabz23I= -----END CERTIFICATE-----
During the upgrade you need to know some information about your current environment. Make sure you record the following information.
If you used Configuration Management in 6.0.2 or earlier versions of Requirements Management or Quality Management applications, if multiple users updated an artifact in a configuration at the same time, inconsistent versions of the artifact might be displayed in the configuration. This problem occurs because multiple versions of the artifact are internally marked as the current version. For example, you might experience the following issues:
This issue no longer occurs in version 6.0.3 and later, but might be present in those versions if you upgraded from an earlier release. You can run the following query to detect if a configuration has more than one current version of an artifact:
SELECT DISTINCT CONFIGURATION_ITEM_ID FROM VVCMODEL.VERSION WHERE CURRENT_COL = 1 GROUP BY CONFIGURATION_ITEM_ID, CONCEPT HAVING COUNT(CONCEPT) > 1
SELECT DISTINCT CONFIGURATION_ITEM_ID FROM VVCMODEL_VERSION WHERE CURRENT_COL = 1 GROUP BY CONFIGURATION_ITEM_ID, CONCEPT HAVING COUNT(CONCEPT) > 1
If the query finds more than one current version, open a command windowshell and enter the following commands:
Important: The -repairMultipleVersionsMarkedAsCurrent repository tools command is available in the latest Interim Fix of each release. You must apply the latest iFix before you can use the command. If you run the query and there are more than one current version of an artifact but the -repairMultipleVersionsMarkedAsCurrent repository tools command is not available, do not upgrade to version .
For Requirements Management
cd \/server
repotools-rm.bat./repotools-rm.sh -repairMultipleVersionsMarkedAsCurrent credentialsFile=credentials.properties
Sample credentials.properties file:
adminUserId=yourAdminUserId
adminPassword=yourAdminPassword
repositoryURL=https://hostname.example.com:port/rm
smartCard=<none>
certificateFile=<none>
kerberos=<none>
For Quality Management
cd \/server
repotools-qm.bat./repotools-qm.sh -repairMultipleVersionsMarkedAsCurrent credentialsFile=credentials.properties
Sample credentials.properties file:
adminUserId=yourAdminUserId
adminPassword=yourAdminPassword
repositoryURL=https://hostname.example.com:port/qm
smartCard=<none>
certificateFile=<none>
kerberos=<none>
For
cd \/server
repotools-rm.bat./repotools-rm.sh -repairMultipleVersionsMarkedAsCurrent credentialsFile=credentials.properties
Sample credentials.properties file:
adminUserId=yourAdminUserId
adminPassword=yourAdminPassword
repositoryURL=https://hostname.example.com:port/rm
smartCard=<none>
certificateFile=<none>
kerberos=<none>
For Quality Management
cd \/server
repotools-qm.bat./repotools-qm.sh -repairMultipleVersionsMarkedAsCurrent credentialsFile=credentials.properties
Sample credentials.properties file:
adminUserId=yourAdminUserId
adminPassword=yourAdminPassword
repositoryURL=https://hostname.example.com:port/qm
smartCard=<none>
certificateFile=<none>
kerberos=<none>
For more information about the repairMultipleVersionsMarkedAsCurrent repository tools command, see Repository tools command to repair multiple versions of an artifact marked as current.
Depending on the size of your database, the utility might take a while to scan the entire database. The server must be running when you run the repository tools command and no restart is required after the command is complete.
If you are prompted for the following message, you can safely ignore it:
repair: YYYY-MM-DD HH:MM:SS,### [Number of configurations] Configurations Modified. Please shutdown the server and run the reindex command.
In order to perform the migration of the or applications that are installed into the same group, two instances of the application must be installed into a target folder. However, does not allow to install two or more instances of the same application into the same group. You can use server rename to move either the or application into a separate installation folder.
If you are using a reverse proxy in your deployment, see the following resources:
In order to perform a server rename procedure, you must install a separate application along with your old installation. There are two options for installing the application:
Examples:
In the following examples, the installation folder corresponding to the existing 6.x is referred to as old_install_dir, and the new 6.x that you will be installing for server rename is referred to as new_install_dir.
The following procedure is for the basic registry to manage users. For LDAP, see Configuring an LDAP or an LDAP/SDBM connection.
cd old_install_dir (Server 1)\server
repotools-jts.bat -generateURLMappings toFile=MAPPINGS.TXT adminUserId=adminUserId adminPassword=adminPassword repositoryURL=https://hostname:port/jts
cd old_install_dir (Server 1)/server
./repotools-jts.sh -generateURLMappings toFile=MAPPINGS.TXT adminUserId=adminUserId adminPassword=adminPassword repositoryURL=https://hostname:port/jts
source=https://hostname:old_https_port/am
target=https://hostname:new_https_port/am
Note: new_https_port is a random port number that should manually be changed since it is not automatically added to the generated mapping file.
repotools-jts.bat./repotools-jts.sh -verifyURLMappings mappingFile=MAPPINGS.TXT adminUserId=adminUserId adminPassword=adminPassword repositoryURL=https://old_hostname:port/jts
repotools-am -help
This command creates the new_install_dir/server/liberty/servers/clm/ folder.
xcopy /s old_install_dir\server\conf\am\indices new_install_dir\server\conf\am\indices
xcopy old_install_dir\server\conf\am\teamserver*.properties new_install_dir\server\conf\am
xcopy old_install_dir\server\conf\am\am.properties new_install_dir\server\conf\am
cp -R old_install_dir/server/conf/am/indices new_install_dir/server/conf/am/indices
cp old_install_dir/server/conf/am/teamserver*.properties new_install_dir/server/conf/am
cp old_install_dir/server/conf/am/am.properties new_install_dir/server/conf/am
First, enter the following command to delete the new_install_dir Apache Derby® database:
del /s /f new_install_dir\server\conf\am\derby\repositoryDB
Enter Y to confirm the delete operation.
rm -rf new_install_dir/server/conf/am/derby/repositoryDB
Then, enter the following command to copy the Apache Derby® database:
xcopy /s old_install_dir\server\conf\am\derby\repositoryDB new_install_dir\server\conf\am\derby\repositoryDB
cp -R old_install_dir/server/conf/am/derby/repositoryDB new_install_dir/server/conf/am/derby/repositoryDB
xcopy old_install_dir\server\liberty\servers\clm\conf\basicUserRegistry.xml new_install_dir\server\liberty\servers\clm\conf
cp old_install_dir/server/liberty/servers/clm/conf/basicUserRegistry.xml new_install_dir/server/liberty/servers/clm/conf
First, make a backup and delete the ltpa.keys file from the old_install_dir server:
del old_install_dir\server\liberty\servers\clm\resources\security\ltpa.keys
rm old_install_dir/server/liberty/servers/clm/resources/security/ltpa.keys
Then copy the ltpa.keys file to the new server:
xcopy old_install_dir\server\liberty\servers\clm\resources\security\ltpa.keys new_install_dir\server\liberty\servers\clm\resources\security
cp old_install_dir/server/liberty/servers/clm/resources/security/ltpa.keys new_install_dir/server/liberty/servers/clm/resources/security
<httpEndpoint id="defaultHttpEndpoint"
host="*"
httpPort="<new_http_port>"
httpsPort="<new_https_port>" />
Note: <new_http_port> is a random port number for HTTP protocol.
old_install_dir/server/liberty/servers/clm/appsold_install_dir\server\liberty\servers\clm\apps
old_install_dir/server/liberty/clmServerTemplate/appsold_install_dir\server\liberty\clmServerTemplate\apps
#RMM
new_install_dir/server/conf
cd old_install_dir\server
repotools-jts.bat -importURLMappings fromFile=MAPPINGS.TXT serverConfFile=serverConf.txt
cd old_install_dir/server
./repotools-jts.sh -importURLMappings fromFile=MAPPINGS.TXT serverConfFile=serverConf.txt
cd old_install_dir\server
server.startup.bat
cd old_install_dir/server
./server.startup
cd new_install_dir\server
server.startup.bat
cd new_install_dir/server
./server.startup
https://hostname:old_https_port/jts/serverRenameStatus
Install the new version applications into a new package group, but do not run the setup wizard. For distributed configurations, install the version applications that correspond to the previously installed applications.
At this point, you can also install the new applications that you did not have in your previous deployment, such as Jazz Reporting Service, Global Configuration Management, and so on. The setup of the upgraded and newly installed applications is completed in a later step.
For information about installing the server, see Installing by using IBM Installation Manager or Installing by using command-line commands.
Install the version applications, but do not run the setup wizard after the installation. For distributed configurations, install the version applications that correspond to the previously installed applications. For information about installing the server, see Installing on IBM i using licensed programs.
Note: You must also install the trial license keys if you use the Enterprise Extension builds.
The extension can be installed in two modes: Model Management Server and Model and Code Management Server. When you are prompted to select the Rhapsody Model Management Deployment mode, choose the mode applicable to your deployment topology. To understand the difference between these two modes as well as to define a list of required licenses, see Client access license management. Select Model and Code Management Server mode, if you use the functionalities provided by application that are not listed for inclusion in Model Management Server mode in your current deployment.
Note: In a clustered environment, you can install a new () application on each node and modify the properties files, or install a new application on the first node and, after modifying the files, copy the entire installation directory to the other nodes and change the node ID.
For the application:
The extension can be installed in two modes: Model Management Server and Model and Code Management Server. When you are prompted to select the Rhapsody Model Management Deployment mode, choose the mode applicable to your deployment topology. To understand the difference between these two modes as well as to define a list of required licenses, see Client access license management. Select Model and Code Management Server mode, if you use the functionalities provided by application that are not listed for inclusion in Model Management Server mode in your current deployment.
Important: Before upgrading, make sure you apply the latest interim fix to your current installation. After you install version , apply the latest interim fix for version if any. This ensures that your new version applications are up-to-date. Make sure you run the repotools-clean command after the application is updated with the patch and restarted before running the addTables command. To check if there are any interim fixes available for your product, visit Fix list for IBM Engineering Lifecycle Management.
Important: Before upgrading, make sure you that you have the latest IBM i OS and Java fixes applied to your system. See IBM i PTFs.
Important: If you use SameSite-enabled browsers, you must edit the server.xml file to add the samesite tag. See Customize the WebSphere Liberty server for SameSite for more details.
ELM is shipped with an embedded WebSphere Liberty server to ease the installation process. However, you can also configure ELM to deploy ELM applications on a stand-alone WebSphere Liberty server. There are certain configurations that you need to do to deploy ELM on stand-alone WebSphere Liberty server.
For example, if the ELM applications are installed at C:\ELM_Liberty_Setup\JazzTeamServer_1 location. The Server folder is available within the JazzTeamServer_1 folder.
For example, if the ELM applications are installed at /opt/IBM/JazzTeamServer_1 location. The Server folder is available within the JazzTeamServer_1 folder.
If you have a large Quality Management application repository with millions of artifacts, the default temporary tablespace QM_TEMP is not enough to handle the temporary files. You must add an additional temporary tablespace to avoid issues. To create an additional temporary tablespace, open a SQL *Plus window and log in as SYSTEM or SYSDBA and enter the following command:
alter tablespace QM_TEMP add tempfile 'ORACLE_BASE/oradata/CLMDB/QM_TEMP2.DBF' size 20m reuse autoextend on next 1m maxsize unlimited;
Where QM_TEMP is the temporary tablespace name, ORACLE_BASE is the absolute path where Oracle is installed, CLMDB is the database name, and QM_TEMP2.DBF is the additional temporary file name that you want to create.
If you have a large Quality Management application repository with millions of artifacts, you can increase some of the Db2 configuration settings to ensure that a successful data migration is achieved. The examples given here are for a repository of about ten million artifacts. Adjust the values according to the size of your data repository. Open a Db2 command window and enter the following commands to increase the configuration settings:
db2 update db cfg for QM using APPLHEAPSZ 60000
db2 update db cfg for QM using LOGFILSIZ 4096
db2 update db cfg for QM using LOGPRIMARY 50
db2 update db cfg for QM using LOGSECOND 100
If you have a large Quality Management application repository with millions of artifacts, you can minimize the upgrade time and maximize the upgrade performance by adding the following Java system variables to the repotools-qm script file:
DEFINE="$DEFINE -Dcom.ibm.team.repository.service.internal.rdb.AbstractDatabaseService.ThreadPoolCount4MigratingVTables=40"
set DEFINE=%DEFINE% -Dcom.ibm.team.repository.service.internal.rdb.AbstractDatabaseService.ThreadPoolCount4MigratingVTables="40"
DEFINE="$DEFINE -Dcom.ibm.team.repository.service.internal.rdb.AbstractDatabaseService.ThreadTimeoutHours4MovingRecords=16"
set DEFINE=%DEFINE% -Dcom.ibm.team.repository.service.internal.rdb.AbstractDatabaseService.ThreadTimeoutHours4MovingRecords="16"
To increase the heap size, in the repotools-app.bat file, search for :default_mx_size and update its value to VMARGS=%VMARGS% -Xmx8G in the repotools-app.sh file, set VMARGS="$VMARGS -Xmx8G".
The Quality Management application online migration is an optional upgrade step that is done while the old server is still running. It migrates data in the live repository to reduce the amount of downtime incurred during normal migration. The data is migrated in such a way as to not affect users on the existing server.
Procedure
Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:
DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL
EXEC sp_updatestats
EXEC DBMS_STATS.GATHER_DATABASE_STATS
For information about the Oracle database DBMS_STATS command, see the Oracle website.
For information about the SQL Server database Update Statistics command, see the SQL Server website.
The teamserver.properties parameter must point to an absolute path on the old server.
cd \server\
repotools-qm.bat -onlineMigrateEstimate teamserver.properties=\server\conf\qm\teamserver.properties logFile=repotools_onlineMigrateEstimate.log
cd /server
./repotools-qm.sh -onlineMigrateEstimate teamserver.properties=/server/conf/qm/teamserver.properties logFile=repotools_onlineMigrateEstimate.log
For more information about the -onlineMigrateEstimate command and its parameters, see Repository tools command for evaluating the online migration process.
The teamserver.properties parameter must point to an absolute path on the old server.
cd \server\
repotools-qm.bat -onlineMigrate teamserver.properties=\server\conf\qm\teamserver.properties logFile=repotools_onlineMigrate.log numStatesPerRun=100 priority=50
cd /server/
./repotools-qm.sh -onlineMigrate teamserver.properties=/server/conf/qm/teamserver.properties logFile=repotools_onlineMigrate.log numStatesPerRun=100 priority=50
For more information about the -onlineMigrate command and its parameters, see Repository tools command for online migration.
You can stop the online migration or revert to a previous state by using other repository tools commands.
To safely stop the online migration at any time, use the -onlineMigrateStop command. For more information, see Repository tools command for stopping online migration.
To revert the database to a previous state, use the -onlineMigrateRevert command. For more information, see Repository tools command for reverting online migration.
The application online migration is an optional upgrade step that is done while the old server is still running. It migrates data in the live repository to reduce the amount of downtime incurred during normal migration. The data is migrated in such a way as to not affect users on the existing server.
Note: In a clustered environment, do this procedure only on the first node. You will replicate this node to other nodes in a later step.
Procedure
Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:
DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL
EXEC sp_updatestats
EXEC DBMS_STATS.GATHER_DATABASE_STATS
For information about the Oracle database DBMS_STATS command, see the Oracle website.
For information about the SQL Server database Update Statistics command, see the SQL Server website.
The teamserver.properties parameter must point to an absolute path on the old server.
cd \server\
repotools-ccm.bat -onlineMigrateEstimate teamserver.properties=\server\conf\ccm\teamserver.properties logFile=repotools_onlineMigrateEstimate.log
cd /server/
./repotools-ccm.sh -onlineMigrateEstimate teamserver.properties=/server/conf/ccm/teamserver.properties logFile=repotools_onlineMigrateEstimate.log
For more information about the -onlineMigrateEstimate command and its parameters, see Repository tools command for evaluating the online migration process.
The teamserver.properties parameter must point to an absolute path on the old server.
cd \server\
repotools-ccm.bat -onlineMigrate teamserver.properties=\server\conf\ccm\teamserver.properties logFile=repotools_onlineMigrate.log numStatesPerRun=100 priority=50
cd /server/
./repotools-ccm.sh -onlineMigrate teamserver.properties=/server/conf/ccm/teamserver.properties logFile=repotools_onlineMigrate.log numStatesPerRun=100 priority=50
For more information about the -onlineMigrate command and its parameters, see Repository tools command for online migration.
You can stop the online migration or revert to a previous state by using other repository tools commands.
To safely stop the online migration at any time, use the -onlineMigrateStop command. For more information, see Repository tools command for stopping online migration.
To revert the database to a previous state, use the -onlineMigrateRevert command. For more information, see Repository tools command for reverting online migration.
If you have an AM application repository with a large number of artifacts, you can reduce the server downtime during migration by running the database migration tasks, while keeping the existing server active.
Note: You can use the onlineMigrateEstimate repotools command to retrieve the number of item states that the online migration command, onlineMigrate, processes.
It is recommended that you use the onlineMigrate command if the number of states for “Type “ID Mappings (168)”:” exceeds 3,000,000.
The average estimated time needed to perform the online migration can be calculated using the following formula:
Online migration time (in hours) = (number of item states) / 500000
For more details about evaluating the online migration process and running online migration, see onlineMigrateEstimate repotools command and onlineMigrate repotools command.
Important: Additional steps are required before you execute the onlineMigrate repotools command. See onlineMigrate repotools command for more details.
To perform online migration keeping the existing server active, open a command prompt with administrative privileges and enter the following commands:
cd <path to EWM/RMM 7.0.3 installation folder specified by user>/server
repotools-ccm -onlineMigrate teamserver.properties=<path to AM 6.0.x/7.0.x Installation folder specified by user>/server/conf/<RMM context root specified by user>/teamserver.properties
numStatesPerRun=400
db2 update db cfg for <RMM DB name> using APPLHEAPSZ <original value * 2>
Create a backup of your WebSphere Application Server profile. If the upgrade fails, you can use the backup to restore the profile.
In a distributed topology, you must complete this step on each application server that hosts the applications.
Note: The command shuts down the server before starting the backup process.
backupConfig.bat Path_to_a_new_compressed_file_to_create_backup_of_profile -username WAS_primary_administrative_user_name -password WAS_administrative_password
For example:
backupConfig.bat C:\WAS_backup\version_6.0.x_profile.zip -username WAS admin -password WAS admin password
Tip: You can restore the backed-up profile by running the restoreConfig.bat command. For example, restoreConfig.bat C:\WAS_backup\version_6.0.x_profile.zip
./backupConfig.sh Path_to_a_new_compressed_file_to_create_backup_of_profile -username WAS_primary_administrative_user_name -password WAS_administrative_password
For example:
./backupConfig.sh /root/WAS_backup/version_6.0.x_profile.zip -username admin -password password
Note: The directory path to the compressed file must exist before running the backup command.
Tip: You can restore the backed-up profile by running the ./restoreConfig.sh command. For example, ./restoreConfig.sh /root/WAS_backup/version_6.0.x_profile.zip
In a distributed topology, you must complete this step on each application server that hosts the applications.
You can use the clm_undeploy.py script to remove all application WAR files that are installed on a single WebShpere Application Server.
You can use the clm_undeploy_distributed.py script to remove all application WAR files that you specify in your command argument as a comma-separated value.
cd \bin
startServer.bat server1
cd /bin
./startServer.sh server1
Continue with the following steps to remove previous installed applications.
cd \bin
startServer.bat server1
cd /bin
./startServer.sh server1
Note: On Windows platforms you must use forward slash in the paths for the location of the Jython script.
wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy.py /server/webapps JazzInstallDirOldVersion/server/webapps
Enter the following command to remove the application WAR files. The clm_undeploy_distributed.py script removes all application WAR files that you specify as a comma-separated value in the command argument. Ensure there are no spaces between the application names.
wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py jts,clmhelp,ldx
wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py ccm
wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py am
wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py qm
wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py rm,converter
wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py relm
wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py dcc
wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py rs
wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py lqe
wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py gc
You can use the clm_was_config.py script to update JAZZ_HOME and configuration location custom properties.
Before you begin
Procedure
Note: On Windows platforms you must use forward slash in the paths for the location of the Jython script and the conf directory.
cd \bin
wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f C:/JazzInstallDir/server/was/clm_was_config.py C:/JazzInstallDir/server/conf -config C:/JazzInstallDir/server/was
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was
Note: On Windows platforms you must use forward slash in the paths for the location of the Jython script and the conf directory.
cd \bin
wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f C:/JazzInstallDir/server/was/clm_was_config.py C:/JazzInstallDir/server/conf -config C:/JazzInstallDir/server/was
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was
In a distributed topology, you must update JAZZ_HOME and configuration location custom properties on each application server that hosts the applications.
\server\conf\rs\WAS_SharedLibrary/server/conf/rs/WAS_SharedLibrary
In a distributed topology, you must complete this step on each application server that hosts the applications.
stopServer.bat server1 -user admin_userid -password admin_password
./stopServer.sh server1 -user admin_userid -password admin_password
./serverShutdown.sh profileName
In addition to QShell, you can use the CL command. Enter QJTS702/STPJAZZSVR on the 5250 command prompt, then press PF4 to prompt for parameters.
In a distributed topology, you must complete this step on each application server that hosts the applications.
Remove the application-related contents from the following directories in the profile:
Node_Name is the application server node name, for example, ADMINIB-SAQDV6VNode01.
Depending on which applications were installed, these directories might be in the profile and can be removed:
Note: If the temp directories have files that are deeper than your MAX_PATH characters, usually 100 characters long, when you try to delete the directories, you might get an Access Denied error. For instructions to delete the directories, see the documentation for your operating system.
In a distributed topology, you must complete this step on each application server that hosts the applications.
Remove the application-related log files from the following logs directory in the profile:
In a distributed topology, you must complete this step on each application server that hosts the applications.
You must clear the WebSphere Application Server class cache to ensure that after the upgrade, the server is not using the previous versions of the classes. There are two types of class cache that must be cleared, the JVM's cache and the OSGi cache. Complete the following steps to clear these caches:
cd \bin
osgiCfgInit.bat/bin
./osgiCfgInit.sh
cd \bin
clearClassCache.bat/bin
./clearClassCache.sh
Note: If you are using the Windows service to start WebSphere Application Server, the command to clear the class cache might not work. In this case you must manually empty the content of the javasharedresources directory. Make sure the service is stopped before attempting to delete the files. Here is an example of the location of the javasharedresources directory: C:\Users\USER_NAME\AppData\Local\javasharedresources. Also note that AppData might be a hidden directory.
Open a command prompt and enter the following commands:
cd \server
server.shutdown.bat
Open a command shell and enter the following command:
cd /server
./server.shutdown
In a distributed topology, you must complete this step on each application server that hosts the applications.
Stop all applications first before stopping .
On the server, open a command prompt and enter the following command:
Note: In a clustered environment, shut down all nodes. You can leave the load-balancer (HAProxy) running unless changes are specifically needed for the new version.
cd \server
server.shutdown.bat
On the AM server, open a command prompt and enter the following command:
cd \server
server.shutdown.bat
On the QM server, open a command prompt and enter the following command:
Note: In a clustered environment, shut down all nodes. You can leave the load-balancer (HAProxy) running unless changes are specifically needed for the new version.
cd \server
server.shutdown.bat
On the RM server, open a command prompt and enter the following command:
cd \server
server.shutdown.bat
On the server, open a command prompt and enter the following command:
cd \server
server.shutdown.bat
On the LQE server, open a command prompt and enter the following command:
cd \server
server.shutdown.bat
On the DCC server, open a command prompt and enter the following command:
cd \server
server.shutdown.bat
On the JRS server, open a command prompt and enter the following command:
cd \server
server.shutdown.bat
On the GC server, open a command prompt and enter the following command:
cd \server
server.shutdown.bat
On , open a command prompt and enter the following command:
cd \server
server.shutdown.bat
On the server, open a command shell and enter the following command:
Note: In a clustered environment, shut down all nodes. You can leave the load-balancer (HAProxy) running unless changes are specifically needed for the new version.
cd /server
./server.shutdown
On the AM server, open a command shell and enter the following command:
cd /server
./server.shutdown
On the QM server, open a command shell and enter the following command:
Note: In a clustered environment, shut down all nodes. You can leave the load-balancer (HAProxy) running unless changes are specifically needed for the new version.
cd /server
./server.shutdown
On the RM server, open a command shell and enter the following command:
cd /server
./server.shutdown
On the server, open a command shell and enter the following command:
cd /server
./server.shutdown
On the LQE server, open a command shell and enter the following command:
cd /server
./server.shutdown
On the DCC server, open a command shell and enter the following command:
cd /server
./server.shutdown
On the JRS server, open a command shell and enter the following command:
cd /server
./server.shutdown
On the GC server, open a command shell and enter the following command:
cd /server
./server.shutdown
On , open a command shell and enter the following command:
cd /server
./server.shutdown
To stop the microservice, open a command windowshell and enter the following commands:
cd Path_To_DCM_Folder
distributedCache.stop.bat JRE_Bin_Path
cd Path_To_DCM_Folder
./distributedCache.stop.sh JRE_Bin_Path
In these commands, Path_To_DCM_Folder is the location where the Distributed Cache Microservice is installed and JRE_Bin_Path is the location of the JRE/Bin folder. The path to the Bin folder is optional. If you do not specify a path, the system uses the default location for the microservice and uses the JRE that is provided by the application.
Starting in version 6.0.6, persistence is enabled by default for the Distributed Cache Microservice. When persistence is enabled, the microservice backs up in-memory distributed caches to disk. This persisted backup is used to initialize local caches on a node that is brought online after going offline in an unplanned manner. The persisted backup enables the node to initialize to the current state.
Also, in version 6.0.6 and later, the Distributed Cache Microservice monitors the online status of the applications' nodes. When a server on a node is shut down, a signal is sent to the microservice. After all nodes of a cluster are offline, the microservice clears all persisted distributed data for that cluster.
Cluster-specific data is stored in a subfolder of the clustering folder, which is specified in the configuration file as shown in the following example:
[Cache]
# Relative or absolute location on the file system to save cache data when the microservice is offline.
# This persisted data is only needed if DCM is restarted while clustered applications are running.
# When a planned shutdown of a clustered application using the cache is underway, it is advisable to delete the persisted data.
-persistentStore = $E{PERSISTENT_STORE, distributedData}
By default, the subfolder is called distributedData. The subfolder contains a directory for each cluster with data on the Distributed Cache Microservice.
After a planned shutdown of ALL nodes in a cluster occurs, delete the folder at this location: server/clustering/cache/<distributedData>/<clusterName>. This deletion allows distributed objects to reinitialize as expected when the nodes come back online.
Note: In a fresh installation, there is no derbyDB under the lqe directory. But if you have already started the server, there might be a derbyDB directory that should be deleted.
Enter the following command to delete the Lifecycle Query Engine Derby database if exists:
del /s /f \server\conf\lqe\derbyDB
Enter Y to confirm the delete operation
Enter the following command to delete the Lifecycle Query Engine Derby database if exists:
rm -rf /server/conf/lqe/derbyDB
Note: The following commands work if you are using the Derby database that is provided with the packaged product. If you changed your Derby database location, update the path accordingly.
Enter the following command to copy the database:
xcopy /s \server\conf\lqe\derbyDB \server\conf\lqe\derbyDB
If prompted, enter D to choose directory.
Enter the following command to copy the Lifecycle Query Engine database:
xcopy /s \server\conf\lqe\derbyDB \server\conf\lqe\derbyDB
If prompted, enter D to choose directory.
Enter the following command to copy the Lifecycle Query Engine database:
cp -R /server/conf/lqe/derbyDB /server/conf/lqe/derbyDB
Enter the following command to copy the Lifecycle Query Engine database:
cp -R /server/conf/lqe/derbyDB /server/conf/lqe/derbyDB
Note: In a fresh installation, there is no derbyDB under the ldx directory. But if you have already started the server, there might be a derbyDB directory that should be deleted.
Enter the following command to delete the Derby database:
del /s /f \server\conf\jts\derby\repositoryDB
Enter Y to confirm the delete operation
Enter the following command to copy the Derby database:
del /s /f \server\conf\ccm\derby\repositoryDB
Enter Y to confirm the delete operation
Enter the following command to delete the Derby database:
del /s /f \server\conf\am\derby\repositoryDB
Enter Y to confirm the delete operation
Enter the following command to delete the Quality Management Derby database:
del /s /f \server\conf\qm\derby\repositoryDB
Enter Y to confirm the delete operation
Enter the following command to delete the Derby database:
del /s /f \server\conf\rm\derby\repositoryDB
Enter Y to confirm the delete operation
Enter the following command to delete the Derby database:
del /s /f \server\conf\relm\derby\repositoryDB
Enter Y to confirm the delete operation
Enter the following command to delete the Global Configuration Management Derby database:
del /s /f \server\conf\gc\derby\repositoryDB
Enter Y to confirm the delete operation
Enter the following command to delete the Data Collection Component Derby database:
del /s /f \server\conf\dcc\derby\repositoryDB
Enter Y to confirm the delete operation
Enter the following command to delete the Link Index Provider Derby database if exists:
del /s /f \server\conf\ldx\derbyDB
Enter Y to confirm the delete operation
Enter the following command to delete the Link Index Provider Derby database if exists:
del /s /f \server\conf\ldx\derbyDB
Enter Y to confirm the delete operation
Enter the following command to delete the Derby database:
rm -rf /server/conf/ccm/derby/repositoryDB
Enter the following command to delete the Derby database:
rm -rf /server/conf/jts/derby/repositoryDB
Enter the following command to delete the Derby database:
rm -rf /server/conf/am/derby/repositoryDB
Enter the following command to delete the Quality Management Derby database:
rm -rf /server/conf/qm/derby/repositoryDB
Enter the following command to delete the Derby database:
rm -rf /server/conf/rm/derby/repositoryDB
Enter the following command to delete the Derby database:
rm -rf /server/conf/relm/derby/repositoryDB
Enter the following command to delete the Global Configuration Management Derby database:
rm -rf /server/conf/gc/derby/repositoryDB
Enter the following command to delete the Data Collection Component Derby database:
rm -rf /server/conf/dcc/derby/repositoryDB
Enter the following command to delete the Link Index Provider Derby database if exists:
rm -rf /server/conf/ldx/derbyDB
Note: The following commands work if you are using the Derby database that is provided with the packaged product. If you changed your Derby database location, update the path accordingly.
Enter the following command to copy the database:
xcopy /s \server\conf\jts\derby\repositoryDB \server\conf\jts\derby\repositoryDB
Enter the following command to copy the database:
xcopy /s \server\conf\ccm\derby\repositoryDB \server\conf\ccm\derby\repositoryDB
Enter the following command to copy the database:
xcopy /s \server\conf\am\derby\repositoryDB \server\conf\am\derby\repositoryDB
Enter the following command to copy the Quality Management database:
xcopy /s \server\conf\qm\derby\repositoryDB \server\conf\qm\derby\repositoryDB
Enter the following command to copy the database:
xcopy /s \server\conf\rm\derby\repositoryDB \server\conf\rm\derby\repositoryDB
Enter the following command to copy the database:
xcopy /s \server\conf\relm\derby\repositoryDB \server\conf\relm\derby\repositoryDB
Enter the following command to copy the Global Configuration Management database:
xcopy /s \server\conf\gc\derby\repositoryDB \server\conf\gc\derby\repositoryDB
Enter the following command to copy the Data Collection Component database:
xcopy /s \server\conf\dcc\derby\repositoryDB \server\conf\dcc\derby\repositoryDB
Enter the following command to copy the Lifecycle Query Engine database:
xcopy /s \server\conf\lqe\derbyDB \server\conf\lqe\derbyDB
If prompted, enter D to choose directory.
Enter the following command to copy the Link Index Provider database:
xcopy /s \server\conf\ldx\derbyDB \server\conf\ldx\derbyDB
If prompted, enter D to choose directory.
The Derby Data Warehouse database for Liberty will be located under the Liberty server. At this point, the Liberty server has not been created. Run the following command to create the Liberty server and then copy the Data Warehouse database:
cd \server
server.startup -create
Enter the following command to copy the Data Warehouse database:
xcopy /s \server\conf\jts\derby\warehouseDB\server\liberty\servers\clm\conf\jts\derby\warehouseDB \server\liberty\servers\clm\conf\jts\derby\warehouseDB
Enter D for directory.
Enter the following command to copy the database:
xcopy /s \server\conf\jts\derby\repositoryDB \server\conf\jts\derby\repositoryDB
Enter the following command to copy the database:
xcopy /s \server\conf\rm\derby\repositoryDB \server\conf\rm\derby\repositoryDB
Enter the following command to copy the database:
xcopy /s \server\conf\ccm\derby\repositoryDB \server\conf\ccm\derby\repositoryDB
Enter the following command to copy the database:
xcopy /s \server\conf\am\derby\repositoryDB \server\conf\am\derby\repositoryDB
Enter the following command to copy the Quality Management database:
xcopy /s \server\conf\qm\derby\repositoryDB \server\conf\qm\derby\repositoryDB
Enter the following command to copy the database:
xcopy /s \server\conf\relm\derby\repositoryDB \server\conf\relm\derby\repositoryDB
Enter the following command to copy the Global Configuration Management database:
xcopy /s \server\conf\gc\derby\repositoryDB \server\conf\gc\derby\repositoryDB
Enter the following command to copy the Data Collection Component database:
xcopy /s \server\conf\dcc\derby\repositoryDB \server\conf\dcc\derby\repositoryDB
Enter the following command to copy the Lifecycle Query Engine database:
xcopy /s \server\conf\lqe\derbyDB \server\conf\lqe\derbyDB
If prompted, enter D to choose directory.
Enter the following command to copy the Link Index Provider database:
xcopy /s \server\conf\ldx\derbyDB \server\conf\ldx\derbyDB
If prompted, enter D to choose directory.
The Derby Data Warehouse database for Liberty will be located under the Liberty server. At this point, the Liberty server has not been created. Run the following command to create the Liberty server and then copy the Data Warehouse database:
cd \server
server.startup -create
Enter the following command to copy the Data Warehouse database:
xcopy /s \server\conf\jts\derby\warehouseDB\server\liberty\servers\clm\conf\jts\derby\warehouseDB \server\liberty\servers\clm\conf\jts\derby\warehouseDB
Enter D for directory.
In a WebSphere Application Sever deployment, the default data warehouse database location is under WebSphere installation directory.
Enter the following command to copy the Data Warehouse database:
xcopy /s WAS_install_dir\OldAppServerHostIntall\jts\derby\conf\warehouseDB WAS_install_dir\AppServerHost6Intall\jts\derby\conf\warehouseDB
Enter D for directory.
Enter the following command to copy the database:
cp -R /server/conf/jts/derby/repositoryDB /server/conf/jts/derby/repositoryDB
Enter the following command to copy the database:
cp -R /server/conf/ccm/derby/repositoryDB /server/conf/ccm/derby/repositoryDB
Enter the following command to copy the database:
cp -R /server/conf/am/derby/repositoryDB /server/conf/am/derby/repositoryDB
Enter the following command to copy the Quality Management database:
cp -R /server/conf/qm/derby/repositoryDB /server/conf/qm/derby/repositoryDB
Enter the following command to copy the database:
cp -R /server/conf/rm/derby/repositoryDB /server/conf/rm/derby/repositoryDB
Enter the following command to copy the database:
cp -R /server/conf/relm/derby/repositoryDB /server/conf/relm/derby/repositoryDB
Enter the following command to copy the Global Configuration Management database:
cp -R /server/conf/gc/derby/repositoryDB /server/conf/gc/derby/repositoryDB
Enter the following command to copy the Data Collection Component database:
cp -R /server/conf/dcc/derby/repositoryDB /server/conf/dcc/derby/repositoryDB
Enter the following command to copy the Lifecycle Query Engine database:
cp -R /server/conf/lqe/derbyDB /server/conf/lqe/derbyDB
Enter the following command to copy the Link Index Provider database:
cp -R /server/conf/ldx/derbyDB /server/conf/ldx/derbyDB
The Derby Data Warehouse database for Liberty will be located under the Liberty server. At this point, the Liberty server has not been created. Run the following command to create the Liberty server and then copy the Data Warehouse database:
cd /server
./server.startup -create
Enter the following command to copy the Data Warehouse database:
cp -R /server/conf/jts/derby/warehouseDB/server/liberty/servers/clm/conf/jts/derby/warehouseDB /server/liberty/servers/clm/conf/jts/derby/warehouseDB
Enter the following command to copy the database:
cp -R /server/conf/jts/derby/repositoryDB /server/conf/jts/derby/repositoryDB
Enter the following command to copy the database:
cp -R /server/conf/rm/derby/repositoryDB /server/conf/rm/derby/repositoryDB
Enter the following command to copy the database:
cp -R /server/conf/ccm/derby/repositoryDB /server/conf/ccm/derby/repositoryDB
Enter the following command to copy the database:
cp -R /server/conf/am/derby/repositoryDB /server/conf/am/derby/repositoryDB
Enter the following command to copy the Quality Management database:
cp -R /server/conf/qm/derby/repositoryDB /server/conf/qm/derby/repositoryDB
Enter the following command to copy the database:
cp -R /server/conf/relm/derby/repositoryDB /server/conf/relm/derby/repositoryDB
Enter the following command to copy the Global Configuration Management database:
cp -R /server/conf/gc/derby/repositoryDB /server/conf/gc/derby/repositoryDB
Enter the following command to copy the Data Collection Component database:
cp -R /server/conf/dcc/derby/repositoryDB /server/conf/dcc/derby/repositoryDB
Enter the following command to copy the Lifecycle Query Engine database:
cp -R /server/conf/lqe/derbyDB /server/conf/lqe/derbyDB
Enter the following command to copy the Link Index Provider database:
cp -R /server/conf/ldx/derbyDB /server/conf/ldx/derbyDB
The Derby Data Warehouse database for Liberty will be located under the Liberty server. At this point, the Liberty server has not been created. Run the following command to create the Liberty server and then copy the Data Warehouse database:
cd /server
./server.startup -create
Enter the following command to copy the Data Warehouse database:
cp -R /server/conf/jts/derby/warehouseDB/server/liberty/servers/clm/conf/jts/derby/warehouseDB /server/liberty/servers/clm/conf/jts/derby/warehouseDB
In a WebSphere Application Sever deployment, the default data warehouse database location is under WebSphere installation.
Enter the following command to copy the Data Warehouse database:
cp -R WAS_install_dir/OldAppServerHostIntall/jts/derby/conf/warehouseDB WAS_install_dir/AppServerHost6Intall/jts/derby/conf/warehouseDB
Attention: Do these steps only if the index files in the teamserver.properties files are located on relative paths or on absolute paths to unstable directories. An example of an unstable directory is old_install_dir. If the index files are in that directory and the directory is uninstalled, you will lose your index files.
Important: This upgrade requires all existing full-text search indexes to be rebuilt. By default, the workitemindex folder contains the full-text index files and is located under JazzInstallDir/server/conf/app/indices. If the workitemindex folder is configured in a different location, such as the WebSphere Application Server profile directory, do not copy the old files. If the workitemindex folder is located at the default location under JazzInstallDir/server/conf/app/indices, after copying the JFS index files, ensure to delete all files in the workitemindex folder. For more details, see this workaround document.
Copy your JFS/text indices from previous installation directory to . For distributed systems go to the appropriate server and copy the files.
To copy your JFS/text indices from a previous installation to version , follow these steps. For distributed systems, go to the appropriate server and copy the files.
If the com.ibm.team.fulltext.indexLocation and com.ibm.team.jfs.index.root.directory properties are pointing to a relative path, for example, com.ibm.team.fulltext.indexLocation=conf/application_context_root/indices/workitemindex, depending on how the previous version of the application was installed or customized, the work item index and JFS index root might be located relative to the WebSphere Application Server profile hosting the applications. For example: , or relative to the application's installation directory.
Change this relative path to an absolute path to a stable location. An example of absolute stable location for work item index looks like this: com.ibm.team.fulltext.indexLocation=_install_dir/server/conf/application_context_root/indices/workitemindex where _install_dir is the location where application is installed. An example of absolute stable location for JFS index root looks like this: com.ibm.team.jfs.index.root.directory=_install_dir/server/conf/application_context_root/indices where _install_dir is the location where application is installed.
If the com.ibm.team.fulltext.indexLocation or com.ibm.team.jfs.index.root.directory properties are pointing to an unstable absolute path, such as path to the old_install_dir directory that might be uninstalled and deleted, change the path to an absolute path that points to a stable location as mentioned previously.
Open a command prompt and enter the following command to copy the full text indices from previous version to . Change the source directory according to the location of the index files:
A performance optimization for SQL Server was introduced in version 6.0 for the database which might result in a failed upgrade if left in place. Open a sqlcmd command line tool and enter the following commands to return the database to an expected state before running the upgrade scripts.
DROP INDEX VERSION_CONCEPT_DX ON VVCMODEL.VERSION
DROP INDEX VERSION_STORAGE_DX ON VVCMODEL.VERSION
Note: You might be prompted for the following error message if the optimization has never been applied before, or you do not have permission to drop index on the database. If you do have permission and you are prompted for the error, you can skip the DROP INDEX command.
"Msg 3701, Level 11, State 7, Line 1
Cannot drop the index 'VVCMODEL.VERSION.VERSION_CONCEPT_DX', because it does not exist or you do not have permission.
Msg 3701, Level 11, State 7, Line 2
Cannot drop the index 'VVCMODEL.VERSION.VERSION_STORAGE_DX', because it does not exist or you do not have permission."
ALTER TABLE VVCMODEL.VERSION ALTER COLUMN CONCEPT NVARCHAR(1000)
ALTER TABLE VVCMODEL.VERSION ALTER COLUMN STORAGE NVARCHAR(1000)
In a distributed environment where applications are installed on separate servers and you want to upgrade all applications from one server (to use either the Upgrade script or Upgrade script in silent mode options), you must be able to access the drive or file system where other applications are installed. The mounted drive must be configured with read-write-execute privileges for the administrator account. chmod -R 777 /opt/IBM/JazzTeamServer. If you cannot access the shared drives from one server, then select Manual Upgrade optionand physically go to each server and perform the upgrade. If using network shares on Windows systems for example, the mount must be in this format: mounted drive letter:\server\conf. An absolute path, such as \\computer name\JTS__install_dir\server\conf, will not work.On UNIX systems for example, the mount must be in this format: mount -t nfs IP Address of the server:/opt/IBM/JazzTeamServer.
To upgrade configuration files, open a command prompt and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:
repotools-jts.bat -migration_jts_updateConfigurationFiles oldJTSHome=\server\conf updateAppServerFiles=no jtsContextRoot=repositoryURL=https://hostname.example.com:port/jts
repotools-jts.bat -addTables
repotools-jts.bat -upgradeWarehouse
repotools-jts.bat -updateLPASampleTemplates
To upgrade configuration files, open a command shell and enter the following commands:
./repotools-jts.sh -migration_jts_updateConfigurationFiles oldJTSHome=/server/conf updateAppServerFiles=no jtsContextRoot=
./repotools-jts.sh -addTables ./repotools-jts.sh -upgradeWarehouse ./repotools-jts.sh -updateLPASampleTemplates
Tomcat user registry only: If you used a Tomcat user registry in your previous installation, the migration command creates a file named passwords.txt in the /\server directory that contains all repository users from the tomcat-users.xml file. Because the tomcat-users.xml file stores one-way-encrypted passwords, it is not possible to migrate these user passwords. Instead, the passwords.txt file contains temporary passwords for each user, which the server administrator must communicate to the users. After the server is started, users can change their temporary passwords.
To upgrade the GC application configuration files, open a command prompt and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:
repotools-gc.bat -migration_gc_updateConfigurationFiles oldApplicationHome=\server\conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
repotools-gc.bat -addTables
To upgrade the GC application configuration files, open a command shell and enter the following commands:
./repotools-gc.sh -migration_gc_updateConfigurationFiles oldApplicationHome=/server/conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
./repotools-gc.sh -addTables
You can use the rs_upgrade wrapper script to upgrade the Report Builder application in this configuration with the -ignoreJTSVersionCheck flag so that the script does not try to connect to to check its version. You must make sure that is already upgraded before you attempt to upgrade the Report Builder application. Open a command prompt and enter the following commands. Note that wrapper script command arguments are different from repotools commands. You do not need an equal sign (=) for -oldApplicationHome, but you need to add a dash sign (-) before each argument, such as -oldApplicationHome or -ignoreJTSVersionCheck:
cd \/server
upgrade\rs\rs_upgrade.batupgrade/rs/rs_upgrade.sh -oldApplicationHome \server\conf/server/conf -ignoreJTSVersionCheck -applicationContextRoot -jtsContextRoot
To upgrade the application configuration files, open a command prompt and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:
repotools-am.bat -migration_ccm_updateConfigurationFiles oldApplicationHome=\server\conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
repotools-am.bat -addTables
To upgrade the application configuration files, open a command shell and enter the following commands:
./repotools-am.sh -migration_ccm_updateConfigurationFiles oldApplicationHome=/server/conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
./repotools-am.sh -addTables
Note: Starting with version 7.x, application is provided as an extension to ; therefore, it is automatically upgraded along with the application.
To upgrade the application configuration files, open a command prompt and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:
repotools-ccm.bat -migration_ccm_updateConfigurationFiles oldApplicationHome=\server\conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
repotools-ccm.bat -addTables
To upgrade the application configuration files, open a command shell and enter the following commands:
./repotools-ccm.sh -migration_ccm_updateConfigurationFiles oldApplicationHome=/server/conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
./repotools-ccm.sh -addTables
Note: In a clustered environment, upgrade only the first node. You will replicate this node in a later step.
To upgrade the application configuration files, open a command prompt and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:
repotools-relm.bat -migration_relm_updateConfigurationFiles oldApplicationHome=\server\conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
repotools-relm.bat -addTables
To upgrade the application configuration files, open a command shell and enter the following commands:
./repotools-relm.sh -migration_relm_updateConfigurationFiles oldApplicationHome=/server/conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
./repotools-relm.sh -addTables
To upgrade the application configuration files, open a command prompt and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:
cd \/server
upgrade\lqe
\lqe
_upgrade.batupgrade/
lqe/lqe_upgrade.sh
-oldApplicationHome \server\conf/server/conf -ignoreJTSVersionCheck -applicationContextRoot
-jtsContextRoot
To upgrade the application configuration files, open a command prompt and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:
repotools-lqe.bat -addTables
To upgrade the application configuration files, open a command shell and enter the following commands:
./repotools-lqe.sh -addTables
To upgrade the application configuration files, open a command prompt and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:
cd \/server
upgrade\ldx
\ldx
_upgrade.batupgrade/
ldx/ldx_upgrade.sh
-oldApplicationHome \server\conf/server/conf -newApplicationHome \server\conf/server/conf
To upgrade the application configuration files, open a command prompt and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:
repotools-ldx.bat -addTables
To upgrade the application configuration files, open a command shell and enter the following commands:
./repotools-ldx.sh -addTables
Note: If you are not upgrading your application at this time, you must have one of the following versions installed for the ETLs to run successfully:
version 6.0.2 or later with the latest interim fix
To upgrade the DCC application configuration files, open a command window and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:
repotools-dcc.bat -migration_dcc_updateConfigurationFiles oldApplicationHome=\server\conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
repotools-dcc.bat -addTables
To upgrade the DCC application configuration files, open a command shell and enter the following commands:
./repotools-dcc.sh -migration_dcc_updateConfigurationFiles oldApplicationHome=/server/conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
./repotools-dcc.sh -addTables
Before you start the Engineering Test Management application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours.
Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:
DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL
EXEC sp_updatestats
EXEC DBMS_STATS.GATHER_DATABASE_STATS
For information about the Oracle database DBMS_STATS command, see the Oracle documentation.
For information about the SQL Server database Update Statistics command, see the SQL Server documentation.
To upgrade the QM application configuration files, open a command prompt and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:
repotools-qm.bat -migration_qm_updateConfigurationFiles oldApplicationHome=\server\conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
repotools-qm.bat -addTables
./repotools-qm.sh -migration_qm_updateConfigurationFiles oldApplicationHome=/server/conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
./repotools-qm.sh -addTables
Note: In a clustered environment, upgrade only the first node. You will replicate this node in a later step.
Before you start the application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours.
Make sure that all previously created RRCx-based drawings are converted to the new diagram format before migrating to application version 7.x.
Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:
DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL
EXEC sp_updatestats
EXEC DBMS_STATS.GATHER_DATABASE_STATS
For information about the Oracle database DBMS_STATS command, see the Oracle documentation.
For information about the SQL Server database Update Statistics command, see the SQL Server documentation.
To upgrade the RM application configuration files and to migrate the link validity data, open a command window and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:
Important: For a multi-JTS environment, the text https://host_name:port/jts should be replaced with the URL specified in the Advanced Admin property, Shared Validity Provider URL, of the JTS that the RM is registered with. If no URL is defined, then use the URL of the JTS that the RM application is registered with. This JTS should already be upgraded to version 7.x and running. The Shared Validity Provider URL is usually set to the URL of the JTS that the LQE is registered with, but use the URL specified in the Advanced Admin property for the upgrade commands.
During the upgrade, after the configuration files are merged, an editor opens in which you can check the teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review.
If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.
cd \server
repotools-rm.bat -migration_rm_updateConfigurationFiles oldApplicationHome=\server\conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= newJTSContextRoot=
Start the application server. On the computer that hosts the application, open a command prompt and enter:
cd \server
server.startup.bat
repotools-rm.bat -rmExportLinkValidity repositoryURL=https://host_name:port/jts adminUserId=admin_user_id adminPassword=admin_password
Stop the application server. On the RM server, open a command prompt and enter the following command:
cd \server
server.shutdown.bat
repotools-rm.bat -addTables
To upgrade the RM application configuration files and to migrate the link validity data, open a command shell and enter the following commands:
Important: For a multi-JTS environment, the text https://host_name:port/jts should be replaced with the URL specified in the Advanced Admin property, Shared Validity Provider URL, of the JTS that the RM is registered with. If no URL is defined, then use the URL of the JTS that the RM application is registered with. This JTS should already be upgraded to version 7.x and running. The Shared Validity Provider URL is usually set to the URL of the JTS that the LQE is registered with, but use the URL specified in the Advanced Admin property for the upgrade commands.
During the upgrade, after the configuration files are merged, an editor opens in which you can check the teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review.
If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.
Make sure that all previously created RRCx-based drawings are converted to the new diagram format before migrating to application version 7.x.
cd /server
./repotools-rm.sh -migration_rm_updateConfigurationFiles oldApplicationHome=/server/conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot=newJTSContextRoot=
Start the application server. On the computer that hosts the application, open a command prompt and enter:
cd \server
server.startup.bat
./repotools-rm.sh -rmExportLinkValidity repositoryURL=https://host_name:port/jts adminUserId=admin_user_id adminPassword=admin_password
Stop the application server. On the RM server, open a command prompt and enter the following command:
cd \server
server.shutdown.bat
./repotools-rm.sh -addTables
The commands that you entered in the previous steps do these tasks:
For more information about these Repository Tools commands, see these help topics:
The Oracle optimizer has several features that attempt to adjust execution plans if the optimizer finds that its cardinality estimates are inaccurate. With ELM applications, however, variation in counts is normal. For example, modules have different numbers of artifacts, view queries return different matches, and the sizes of global configurations varies. This can lead to SQL plan instability, where the optimizer is frequently doing hard parses to try and find better plans. These hard parses are expensive, and can lead to view timeouts. It is recommended to disable Oracle's adaptive features. They typically do not improve on the initial execution plans, and the cost of the hard parses is too high to incur repeatedly. For more information, see Oracle tuning.
There is a migration verification done for after the upgrade that generates a report in the server directory. By default, this report contains 10% (value of 1) of the migration verification. You can create an environment variable and set the verification to the level that you want. A value of 0 does not validate anything and no report is generated. A value of 10 produces a report with all data validation. The higher the percentage of the data to be validated, the more time is required to complete the upgrade.
To create an environment variable follow these steps:
Note: The variable name must be typed exactly as shown.
The report generation is automatic and a report named MigrationValidation.html is created in the _install_dir\server directory. Subsequent generated reports will have a time stamped after the file name.
export validateData=a number between 0 and 10
Note: The variable name must be typed exactly as shown.
The report generation is automatic and a report named MigrationValidation.html is created in the _install_dir/server directory. Subsequent generated reports will have a time stamped after the file name.
This script uses Repository Tools commands to update the configuration files and update the databases and data warehouse schemas to version . Follow the on-screen prompts to upgrade your application. For more information, see Upgrade script files.
In a distributed environment where applications are installed on separate servers and you want to upgrade all applications from one server (to use either the Upgrade script or Upgrade script in silent mode options), you must be able to access the drive or file system where other applications are installed. The mounted drive must be configured with read-write-execute privileges for the administrator account. chmod -R 777 /opt/IBM/JazzTeamServer. If you cannot access the shared drives from one server, then select Manual Upgrade option and physically go to each server and perform the upgrade. If using network shares on Windows systems for example, the mount must be in this format: mounted drive letter:\server\conf. An absolute path, such as \\computer name\JTS__install_dir\server\conf, will not work.On UNIX systems for example, the mount must be in this format: mount -t nfs IP Address of the server:/opt/IBM/JazzTeamServer.
Note: Check if the \conf\rs\db folder is available in your new installation. If the folder is available, delete the folder.
Important: Although the script file is in the upgrade/application context root directory, the file must be run from the server directory. Also if your path includes spaces, ensure that is enclosed in double quotation marks.
111Note: After the upgrade, the new server automatically rebuilds the indexes in the background after you start it. This might take a while depending on the size of your index files. Results of full-text searches might be incomplete until the reindexing operation is finished; the progress of the reindex is periodically written to the server log file and also displayed as a system alert in the web UI banner.
Before you Begin: Ensure that you have a JDBC environment variable that points to the ojdbc8.jar located in the directory. For more information, see Setting up an Oracle database.
To upgrade open a command prompt with administrative privileges and enter the following commands:
During the upgrade, after the configuration files are merged, a window opens in which you can check the teamserver.properties file. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled.
An absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=JTS__install_dir/server/conf/jts/indices/workitemindex, where JTS__install_dir is the location where is installed.
If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.
Tomcat user registry only: If you used a Tomcat user registry in your previous installation, the migration command creates a file named passwords.txt in the \server directory that contains all repository users from the tomcat-users.xml file. Because the tomcat-users.xml file stores one-way-encrypted passwords, it is not possible to migrate these user passwords. Instead, the passwords.txt file contains temporary passwords for each user, which the server administrator must communicate to the users. After the server is started, users can change their temporary passwords.
To upgrade the Global Configuration Management application open a command prompt with administrative privileges and enter the following commands:
Ensure that you can connect to with the network path you use in the -newJTSHome argument.
During the upgrade, after the configuration files are merged, a window opens in which you can check the Global Configuration Management teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled.
An absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=GC__install_dir/server/conf/gc/indices/workitemindex where GC__install_dir is the location where the Global Configuration Management application is installed.
If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.
To upgrade application open a command prompt with administrative privileges and enter the following commands:
Ensure that you can connect to with the network path you use in the -newJTSHome argument.
During the upgrade, after the configuration files are merged, a window opens in which you can check the teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled.
An absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=CCM__install_dir/server/conf/am/indices/workitemindex where CCM__install_dir is the location where is installed.
If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.
Note: Starting with version 7.x, application is provided as an extension to ; therefore, it is automatically upgraded along with the application.
To upgrade application open a command prompt with administrative privileges and enter the following commands:
Ensure that you can connect to with the network path you use in the -newJTSHome argument.
During the upgrade, after the configuration files are merged, a window opens in which you can check the Change and Configuration teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled.
An absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=CCM__install_dir/server/conf/ccm/indices/workitemindex where CCM__install_dir is the location where application is installed.
If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.
Note: In a clustered environment, upgrade only the first node. You will replicate this node in a later step.
To upgrade the application open a command prompt with administrative privileges and enter the following commands:
Ensure that you can connect to with the network path you use in the -newJTSHome argument.
During the upgrade, after the configuration files are merged, a window opens in which you can check the teamserver.properties file. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled.
An absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=__install_dir/server/conf/relm/indices/workitemindex where __install_dir is the location where the application is installed.
If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.
Note: If you are not upgrading your application at this time, you must have one of the following versions installed for the ETLs to run successfully:
version 6.0.2 or later with the latest interim fix
To upgrade the Data Collection Component application open a command prompt with administrative privileges and enter the following commands:
Ensure that you can connect to with the network path you use in the -newJTSHome argument.
During the upgrade, after the configuration files are merged, a window opens in which you can check the Data Collection Component teamserver.properties file. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled.
An absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=DCC__install_dir/server/conf/dcc/indices/workitemindex where DCC__install_dir is the location where the Data Collection Component application is installed.
If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.
To upgrade the Report Builder application open a command prompt with administrative privileges and enter the following commands:
If you used any ready-to-use reports in the previous release and want to import them during the upgrade, use the importReportsOnStartup parameter.
Ensure that you can connect to with the network path you use in the -newJTSHome argument.
During the upgrade, after the configuration files are merged, a window opens in which you can check the Report Builder app.properties file.
To upgrade the Lifecycle Query Engine application open a command prompt with administrative privileges and enter the following commands:
Ensure that you can connect to with the network path you use in the -newJTSHome argument.
During the upgrade, after the configuration files are merged, a window opens in which you can check the Lifecycle Query Engine lqe.properties file.
To upgrade the Link Index Provider application open a command prompt with administrative privileges and enter the following commands:
Before you start the Quality Management application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours.
Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:
DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL
EXEC sp_updatestats
EXEC DBMS_STATS.GATHER_DATABASE_STATS
For information about the Oracle database DBMS_STATS command, see the Oracle documentation.
For information about the SQL Server database Update Statistics command, see the SQL Server documentation.
To upgrade Quality Management application open a command prompt with administrative privileges and enter the following commands:
Ensure that you can connect to with the network path you use in the -newJTSHome argument.
During the upgrade, after the configuration files are merged, a window opens in which you can check the Quality Management teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled. The absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=QM__install_dir/server/conf/qm/indices/workitemindex where QM__install_dir is the location where Quality Management application is installed.
If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.
Note: In a clustered environment, upgrade only the first node. You will replicate this node in a later step.
Before you start the application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours.
Make sure that all previously created RRCx-based drawings are converted to the new diagram format before migrating to application version 7.x.
Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:
DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL
EXEC sp_updatestats
EXEC DBMS_STATS.GATHER_DATABASE_STATS
For information about the Oracle database DBMS_STATS command, see the Oracle documentation.
For information about the SQL Server database Update Statistics command, see the SQL Server documentation.
To upgrade the application that is installed on the same server as and migrate the link validity data, see this deployment wiki document.
To upgrade application open a command prompt with administrative privileges and enter the following commands:
Ensure that you can connect to with the network path you use in the -newJTSHome argument.
Important: It is assumed that you have upgraded and deployed and all other applications except for the application and performed all the necessary pre-upgrade steps. To learn about link validity data migration and its options, see the rm_upgrade script topic.
Important: For a multi-JTS environment, the text https://host_name:port/jts should be replaced with the URL specified in the Advanced Admin property, Shared Validity Provider URL, of the JTS that the RM is registered with. If no URL is defined, then use the URL of the JTS that the RM application is registered with. This JTS should already be upgraded to version 7.x and running. The Shared Validity Provider URL is usually set to the URL of the JTS that the LQE is registered with, but use the URL specified in the Advanced Admin property for the upgrade commands.
During the upgrade, after the configuration files are merged, an editor opens in which you can check the teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review.
If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.
Make sure that all previously created RRCx-based drawings are converted to the new diagram format before migrating to application version 7.x.
Important: You must run the rebuildTextIndices repotool command to rebuild the indexes for the application.
To upgrade open a command shell and enter the following commands:
During the upgrade, after the configuration files are merged, an editor opens in which you can check the teamserver.properties file. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled. The absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=JTS__install_dir/server/conf/jts/indices/workitemindex where JTS__install_dir is the location where is installed.
If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.
Tomcat user registry only: If you used a Tomcat user registry in your previous installation, the migration command creates a file named passwords.txt in the /server directory that contains all repository users from the tomcat-users.xml file. Because the tomcat-users.xml file stores one-way-encrypted passwords, it is not possible to migrate these user passwords. Instead, the passwords.txt file contains temporary passwords for each user, which the server administrator must communicate to the users. After the server is started, users can change their temporary passwords.
To upgrade the Global Configuration Management application open a command shell and enter the following commands:
Ensure that you can connect to with the network path you use in the -newJTSHome argument.
During the upgrade, after the configuration files are merged, an editor opens in which you can check the Global Configuration Management teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled. The absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=GC__install_dir/server/conf/gc/indices/workitemindex where GC__install_dir is the location where Global Configuration Management application is installed.
If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.
To upgrade the application open a command shell and enter the following commands:
Ensure that you can connect to with the network path you use in the -newJTSHome argument.
During the upgrade, after the configuration files are merged, an editor opens in which you can check the teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled. The absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=CCM__install_dir/server/conf/am/indices/workitemindex where CCM__install_dir is the location where is installed.
If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.
Note: Starting with version 7.x, application is provided as an extension to ; therefore, it is automatically upgraded along with the application.
To upgrade the application open a command shell and enter the following commands:
Ensure that you can connect to with the network path you use in the -newJTSHome argument.
During the upgrade, after the configuration files are merged, an editor opens in which you can check the teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled. The absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=CCM__install_dir/server/conf/ccm/indices/workitemindex where CCM__install_dir is the location where application is installed.
If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.
Note: In a clustered environment, upgrade only the first node. You will replicate this node in a later step.
To upgrade the application open a command shell and enter the following commands:
Ensure that you can connect to with the network path you use in the -newJTSHome argument.
During the upgrade, after the configuration files are merged, an editor opens in which you can check the teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled. The absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=__install_dir/server/conf/relm/indices/workitemindex where __install_dir is the location where the application is installed.
If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.
Note: If you are not upgrading your application at this time, you must have one of the following versions installed for the ETLs to run successfully:
version 6.0.2 or later with the latest interim fix
To upgrade the Data Collection Component application open a command shell and enter the following commands:
Ensure that you can connect to with the network path you use in the -newJTSHome argument.
During the upgrade, after the configuration files are merged, an editor opens in which you can check the Data Collection Component teamserver.properties file. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled. The absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=DCC__install_dir/server/conf/dcc/indices/workitemindex where DCC__install_dir is the location where Data Collection Component application is installed.
If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.
To upgrade the Report Builder application open a command shell and enter the following commands:
If you used any ready-to-use reports in the previous release and want to import them during the upgrade, use the importReportsOnStartup parameter.
Ensure that you can connect to with the network path you use in the -newJTSHome argument.
During the upgrade, after the configuration files are merged, a window opens in which you can check the Report Builder app.properties file.
To upgrade the Lifecycle Query Engine application open a command prompt with administrative privileges and enter the following commands:
Ensure that you can connect to with the network path you use in the -newJTSHome argument.
During the upgrade, after the configuration files are merged, a window opens in which you can check the Lifecycle Query Engine lqe.properties file.
To upgrade the Link Index Provider application open a command prompt with administrative privileges and enter the following commands:
Before you start the Quality Management application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours.
Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:
DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL
EXEC sp_updatestats
EXEC DBMS_STATS.GATHER_DATABASE_STATS
For information about the Oracle database DBMS_STATS command, see the Oracle documentation.
For information about the SQL Server database Update Statistics command, see the SQL Server documentation.
To upgrade Quality Management application open a command shell and enter the following commands:
Ensure that you can connect to with the network path you use in the -newJTSHome argument.
During the upgrade, after the configuration files are merged, an editor opens in which you can check the Quality Management teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled. The absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=QM__install_dir/server/conf/qm/indices/workitemindex where QM__install_dir is the location where Quality Management application is installed.
If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.
Note: In a clustered environment, upgrade only the first node. You will replicate this node in a later step.
Before you start the application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours.
Make sure that all previously created RRCx-based drawings are converted to the new diagram format before migrating to application version 7.x.
Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:
DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL
EXEC sp_updatestats
EXEC DBMS_STATS.GATHER_DATABASE_STATS
For information about the Oracle database DBMS_STATS command, see the Oracle documentation.
For information about the SQL Server database Update Statistics command, see the SQL Server documentation.
To upgrade the application that is installed on the same server as and migrate the link validity data, see this deployment wiki document.
cd /server
upgrade/rm/rm_upgrade.sh -oldApplicationHome /server/conf -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt
To upgrade application open a command shell and enter the following commands:
Ensure that you can connect to with the network path you use in the -newJTSHome argument.
Important: It is assumed that you have upgraded and deployed and all other applications except for the application and performed all the necessary pre-upgrade steps. To learn about link validity data migration and its options, see the rm_upgrade script topic.
Important: For a multi-JTS environment, the text https://host_name:port/jts should be replaced with the URL specified in the Advanced Admin property, Shared Validity Provider URL, of the JTS that the RM is registered with. If no URL is defined, then use the URL of the JTS that the RM application is registered with. This JTS should already be upgraded to version 7.x and running. The Shared Validity Provider URL is usually set to the URL of the JTS that the LQE is registered with, but use the URL specified in the Advanced Admin property for the upgrade commands.
During the upgrade, after the configuration files are merged, an editor opens in which you can check the teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review.
If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.
Make sure that all previously created RRCx-based drawings are converted to the new diagram format before migrating to application version 7.x.
Note: The log4j configuration files are not merged. If you customized these files in previous versions, you must manually migrate your customized settings over to the new log4j2.xml files. Log4j libraries were upgraded in ELM 7.0.2 SR1 iFix015. If you are upgrading from an older version, you must migrate your customized settings from the log4j.properties file to the new log4j2.xml files.
The Oracle optimizer has several features that attempt to adjust execution plans if the optimizer finds that its cardinality estimates are inaccurate. With ELM applications, however, variation in counts is normal. For example, modules have different numbers of artifacts, view queries return different matches, and the sizes of global configurations varies. This can lead to SQL plan instability, where the optimizer is frequently doing hard parses to try and find better plans. These hard parses are expensive, and can lead to view timeouts. It is recommended to disable Oracle's adaptive features. They typically do not improve on the initial execution plans, and the cost of the hard parses is too high to incur repeatedly. For more information, see Oracle tuning.
Enter the following command to set JAVA_HOME at job-scope:
ADDENVVAR ENVVAR (JAVA_HOME)
VALUE('/QOpenSys/QIBM/ProdData/JavaVM/jdk11/64bit') LEVEL(*JOB)
Run the following command to check the version of Java:
QSH CMD('java -version)
upgrade/jts/jts_upgrade.sh -oldJTSHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf
upgrade/ccm/ccm_upgrade.sh -oldApplicationHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf
upgrade/qm/qm_upgrade.sh -oldApplicationHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf
upgrade/rm/rm_upgrade.sh -oldApplicationHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf
Perform the steps mentioned in section Migrating the link validity data in a single-server topology using upgrade script with interaction provided in the Deployment wiki. Although the Deployment wiki provides steps for a server with RM and JTS installed on the same application server, the steps will work for a distributed server as well.upgrade/relm/relm_upgrade.sh -oldApplicationHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf
upgrade/gc/gc_upgrade.sh -oldApplicationHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf
upgrade/rs/rs_upgrade.sh -oldApplicationHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf
upgrade/lqe/lqe_upgrade.sh -oldApplicationHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf
upgrade/ldx/ldx_upgrade.sh -oldApplicationHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf
upgrade/dcc/dcc_upgrade.sh -oldApplicationHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf
Note: As an alternative, you can run the QJTS703/UPGJAZZSVR CL command to upgrade the server.
Note: After running the update configuration files repository tools commands for and applications, some of the directory references in the teamserver.properties files point to the prior version work directory. You can keep the indices in the prior version directory, if you do not plan to delete or clean up that directory.
You could also copy the indices to a new location in the new work directory and modify the teamserver.properties file. For example, suppose
the updated teamserver.properties file includes com.ibm.team.jfs.index.root.directory=/QIBM/UserData/JazzTeamServer702/server/conf/jts/indices but your new work directory is
/QIBM/UserData/JazzTeamServer703/server/conf. You can recursively copy these files to a new location and modify the teamserver.properites file. This is not required.
upgrade/liberty_upgrade.sh serverName /QIBM/UserData/JazzTeamServer<old_version>/server/conf
If you would like to maintain results saved in 6.x, you must copy the ExportResults folder from the 6.x installation directory to the 7.x installation directory. By default, the ExportResults folder is available at Jazz_install_dir/server/conf/rs directory. You must also review the export.result.default.dir property in Jazz_install_dir/server/conf/rs/app.properties file if custom paths are specified.
All adapters in your Engineering Test Management application including out of the box adapters and custom adapters such as the, NI Test Integration Adapter, or the IBM Engineering Test Management Adapter for UFT, must be upgraded to the same version as of the server. If you have any custom adapters, the .ini files of those adapters must be copied to the new installation directory after the upgrade. For example, if you are using the UTF adapter, navigate to the <old install path>\server\conf\qm\provision_profiles directory and copy the com.ibm.rqm.adapter.qtp.web.ini file to the <new install path>\server\conf\qm\provision_profiles directory.
For example, to manually copy the HP Unified Functional Testing (UFT) Adapter, go to \server\conf\qm\provision_profiles/server/conf/qm/provision_profiles and copy the com.ibm.rqm.adapter.qtp.web.ini file to the \server\conf\qm\provision_profiles/server/conf/qm/provision_profiles directory.
.In a distributed topology, you must complete this step on each application server that hosts the applications.
Note: On Linux systems, an error might occur when you start the (RM) server from a command line (headless mode). For troubleshooting, see Fixing a converter issue while using the server in headless mode on a Linux system.
Before you Begin: Ensure that you have a JDBC environment variable that points to the ojdbc8.jar located in the directory. For more information, see Setting up an Oracle database.
Before you begin: Ensure that you have a JDBC environment variable to point to the JRE8 JDBC driver located in the directory. For more information, see Setting up an SQL Server database.
cd \bin
startServer.bat server1
cd /bin
./startServer.sh server1
You can use clm_deploy.pyclm_deploy_distributed.py deploy application WAR files. This script also maps the security roles for the appropriate applications for non-external user registries.
If you are using LDAP, complete the following steps to map the security roles to your LDAP groups. Note that the groups must be setup on the LDAP server prior to completing this mapping.
RoleMapping = {
'jts' : {
'JazzAdmins' : {
'mappedUser': None,
'mappedGroup': "cn=JazzAdmins,cn=members,o=ldap.server.com",
'AllowAccessToEveryone':'No',
'AllowAccessToAllAuthenticatedUsers':'No'
},
'JazzUsers' : {
'mappedUser': None,
'mappedGroup': "cn=JazzUsers,cn=members,o=ldap.server.com",
'AllowAccessToEveryone':'No',
'AllowAccessToAllAuthenticatedUsers':'No'
},
'JazzGuests' : {
'mappedUser':None,
'mappedGroup': "cn=JazzGuests,cn=members,o=ldap.server.com",
'AllowAccessToEveryone':'No',
'AllowAccessToAllAuthenticatedUsers':'No'
},
'JazzProjectAdmins' : {
'mappedUser': None,
'mappedGroup': "cn=JazzProjectAdmins,cn=members,o=ldap.server.com",
'AllowAccessToEveryone':'No',
'AllowAccessToAllAuthenticatedUsers':'No'
}
},
About this task
The clm_deploy.py script installs all application WAR files that are available in the webapps directory into a single WebSphere Application Server node.
The clm_deploy_distributed.py script can be used to install any application WAR files that are available in the webapps directory, if you specify them in your command argument as a comma-separated list.
Note: The web archive applications must have a .war extension.
Procedure
To deploy applications on a single WebSphere Application Server, complete this step:
Note: On Windows platforms you must use forward slash in the paths for the location of the Jython script and the webapps directory.
cd \bin
wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy.py nodeName server1 JazzInstallDir/server/webapps -config JazzInstallDir/server/was
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_deploy.py nodeName server1 /server/webapps -config /server/was
To deploy applications in a distributed WebSphere Application Server environment, complete these steps. Replace nodeName and server1 with your WebSphere Application Server node name and server name:
Note: On Windows platforms you must use forward slash in the paths for the location of the Jython script and the webapps directory.
cd \bin
wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps jts,clmhelp,ldx -config JazzInstallDir/server/was
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps jts,clmhelp,ldx -config /server/was
cd \bin
wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps ccm -config JazzInstallDir/server/was
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps ccm -config /server/was
cd \bin
wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps am -config JazzInstallDir/server/was
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps am -config /server/was
cd \bin
wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps qm -config JazzInstallDir/server/was
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps qm -config /server/was
cd \bin
wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps rm,converter
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps rm,converter
cd \bin
wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps relm
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps relm
cd \bin
wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps dcc
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps dcc
cd \bin
wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps rs
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps rs
cd \bin
wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps lqe
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps lqe
cd \bin
wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps gc
cd /bin
./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps gc
cd WAS_Profile_Dir\bin
stopServer.bat server1 -user WAS_USER -password WAS_PASSWORD
startServer.bat server1
cd WAS_Profile_Dir/bin
./stopServer.sh server1 -user WAS_USER -password WAS_PASSWORD
./startServer.sh server1
In a distributed topology, you must complete this step on each application server that hosts the applications.
WAR file locations: By default, the WAR files are copied into the _install_dir/server/webapps directory by Installation Manager, unless you specified a different directory.
Depending on the applications that you installed, the following web applications might be available for deployment:
Important: If you work in an environment such as AIX that does not support converter, you must install the version of the converter.war on the dedicated converter server. For detailed information, see the Delegated Configuration section of the Converter Application Configuration and Troubleshooting Guide.
Note: If you want to install the version of the converter.war file on the dedicated converter server, see the Delegated Configuration section of the Converter Application Configuration and Troubleshooting Guide.
The jts_war, am_war, qm_war, and ccm_war applications must have the same authentication methods for their users and use the same security group mapping.
These repository groups are associated with every Jazz implementation and must be mapped to a particular group that contains the authorized users. If you are using LDAP, these groups must be set up on the LDAP server prior to completing this mapping. If you are mapping these repository groups to individual users, select the repository group and click Map Users.
Note: In future, if there are changes to the LDAP configuration level, you must remap the security roles to the user or repository group for JTS and other installed applications.
In a distributed topology, you must complete this step on each application server that hosts the applications.
Log on to the Integrated Solutions Console and start these applications:
If you have installed any new applications apart from the ones you have upgraded, you must run the setup wizard to register these new applications with .
The Distributed Cache Microservice was first introduced in version 6.0.5. If you are upgrading your clustered environment from version 6.0.4, follow the procedures in the Interactive Installation Guide to install and register a new DCM.
When you install the new version of the application, a new version of Distributed Cache Microservice is installed at the default location, JazzInstallDir/server/clustering/cache.
In particular, ensure the following configuration properties in the distributedCache.cfg file are merged:
Note: Starting in version 6.0.6.1, the version of Jetty that is used for DCM has changed. As a result, the allowRenegotiate property in the distributedCache.cfg file changed to renegotiationAllowed with the default value still being false.
To replicate the upgraded application to all other nodes in the clustered environment:
Note: Copying the entire installation directory works if an HAProxy is used. If you use IBM HTTP Server for load balancing, to avoid problems only copy the conf directory.
Important: The upgrade command does not upgrade the server.startup file. If you customized this file in your previous installation, you must manually merge your customized settings.
com.ibm.team.repository.servlet.sso_clientId
JAVA_OPTS="$JAVA_OPTS -Dcom.ibm.team.repository.cluster.nodeId="ccm1""
JAVA_OPTS="$JAVA_OPTS -Dcom.ibm.team.repository.service.internal.db.allowConcurrentAccess=true"
JAVA_OPTS="$JAVA_OPTS -Dretry.count=0"
JAVA_OPTS="$JAVA_OPTS -Dretry.wait=10"
Important: Examine the /server/clustering/cache/distributedCache.cfg file and merge any customized settings that you made in the previous instance of the file. Do not use the microservice from a previous release with a newer version of . Always merge customized settings from an existing instance of the Distributed Cache Microservice into the new instance that you install with .
System administrators can upgrade Eclipse Amlen from earlier versions or ifixes. System administrators can also upgrade to Eclipse Amlen from IBM® Watson IoT Platform Message Gateway or IBM IoT MessageSight. See Upgrading to Eclipse Amlen.
Before starting the servers in your clustered environment, restart Eclipse Amlen by using the CleanStore button. The CleanStore button ensures that the store is cleaned as part of the shutdown process.
Note: If you customized your server.startup script in the previous installation, you must manually MERGE your customized settings into the new server.startup file. Ensure to have a backup of the new server.startup file before customizing it.
Important: If you are using IBM WebSphere Liberty, have applications distributed across multiple servers, and want to upgrade manually, you must migrate your certificates before your start the servers.
In a distributed topology, you must complete this step on each application server that hosts the applications.
Note: In a clustered environment, start the Distributed Cache Microservice and first, verify that they are working properly by logging in to the servers, and then start all the other application nodes.
Before you Begin: Ensure that you have a JDBC environment variable that points to the ojdbc8.jar located in the directory. For more information, see Setting up an Oracle database.
Before you begin: Ensure that you have a JDBC environment variable to point to the JRE8 JDBC driver located in the directory. For more information, see Setting up an SQL Server database.
Start all of the version application servers:
Start the version application server:
cd \server
server.startup.bat
Run the following command:
repotools-relm -reindex all
Open a command prompt and enter:cd \server
server.startup.bat
cd \server
server.startup.bat
cd \server
server.startup.bat
cd \server
server.startup.bat
cd \server
server.startup.bat
cd \server
server.startup.bat
cd \server
server.startup.bat
cd \server
server.startup.bat
cd \server
server.startup.bat
cd \server
server.startup.bat
repotools-relm -reindex all
cd \server
server.startup.bat
cd \server
server.startup.bat
cd /server
./server.startup
Run the following command:
repotools-relm -reindex all
Open a command shell and enter:cd /server
./server.startup
cd /server
./server.startup
cd /server
./server.startup
cd /server
./server.startup
cd /server
./server.startup
cd /server
./server.startup
cd /server
./server.startup
cd /server
./server.startup
cd /server
./server.startup
cd /server
./server.startup
repotools-relm -reindex all
cd /server
./server.startup
cd /server
./server.startup
You can migrate your certificate from your previous Tomcat Liberty installation to import and use those certificates with your new WebSphere Liberty server.
Before you begin
You must at least start and stop the server one time before you can complete this procedure.
Procedure
<keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>
Complete these steps on the :
<keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>
Complete these steps on the application server:
<keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>
Complete these steps on the Quality Management application server:
<keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>
Complete these steps on the application server:
<keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>
Complete these steps on the application server:
<keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>
Complete these steps on the Data Collection Component application server:
<keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>
Complete these steps on the Report Builder application server:
<keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>
Complete these steps on the Lifecycle Query Engine application server:
<keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>
Complete these steps on the Global Configuration Management application server:
<keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>
For more information, see Enabling SSL communication for the Liberty.
If you used ready-to-use reports in your , you must reimport them after you upgrade to version .
Note: The following steps are not required if you used the importReportsOnStartup parameter during the upgrade. The reports will be imported after the server is started.
Procedure
When the application is started after the upgrade, a migration takes place in the background. Open a browser and go to the admin page at https://host.example.com:port/lqe/web. If the server migration has completed, you will be redirected to the home page. If the migration is still in progress, the migration status page opens. In this case, wait for the migration to complete and then you will be redirected to the home page.
Note: RMM version 6.x did not contribute to LQE and LDX. However during the upgrade, RMM is converted to CCM with AM Extension for CCM application which supports the Tracked Resource Set (TRS) specification. Therefore, it is recommended to register corresponding TRS feeds as data sources in both LQE and LDX applications. If LQE or LDX are installed on a separate JTS from the CCM application, perform the steps described in Connecting Lifecycle Query Engine to applications that use a different Jazz Team Server, else perform the steps described in Connecting Lifecycle Query Engine to applications that use the same Jazz Team Server.
You must register the corresponding TRS feeds to fetch details of OSLC links established between EWM artifacts owned by the upgraded server and artifacts owned by other EWM or ETM applications. Details of such OSLC links are fetched from LQE when generating JRS reports, where LDX is used to display data in Web Clients.
If you did not configure the data warehouse in your previous installation and want to configure a data warehouse for version , follow these steps:
Note: You do not have to run the setup wizard to set up the version server. The setup wizard is needed only if you did not configure the data warehouse in the previous installation and now want to configure it.
You must obtain new licenses for version applications, if you are upgrading from any earlier version. Licenses for version 6.x or 7.x applications do not work with version applications.
If you previously used floating, token, or authorized user single install licenses, install their version counterparts. Your existing user license assignments are retained during installation of version licenses.
You can obtain your permanent licenses from Passport Advantage when downloading your version 7.x eAssembly.
To update your token licenses:
For more information about licenses, see Managing licenses.
If you are using Lifecycle Query Engine, complete the following steps after you upgrade your application. Note that these steps might take some time to complete depending on the size of your repository.
Note: If the DNG TRS 2.0 data sources already exist in Lifecycle Query Engine, you do not need to remove and add them back again. You can just reindex the data sources.
The URL for DNG Process Resources (TRS 2.0) is https://RM_Server:port/rm/process-trs2 and the URL for DNG Resources (TRS 2.0) is https://RM_Server:port/rm/trs2. After the data sources are added, Lifecycle Query Engine starts building the initial indices.
If you are using Lifecycle Query Engine, complete the following steps after you upgrade your application. Note that these steps might take some time to complete depending on the size of your repository.
In version 6.x, the RMM application did not contribute to LQE or LDX. However, because you are migrating your RMM application to , the native CCM data source must be reindexed in LQE. Note that these steps might take some time to complete depending on the size of your repository.
If you are using Lifecycle Query Engine, complete the following steps after you upgrade your Quality Management application. Note that these steps might take some time to complete depending on the size of your repository.
If you are using Lifecycle Query Engine, complete the following steps after you upgrade your Global Configuration Management application. Note that these steps might take some time to complete depending on the size of your repository.
If you used IBM Installation Manager to install Jazz Authorization Server, you can use the Update feature of Installation Manager to upgrade your Jazz Authorization Server.
Before you begin
Procedure
These configuration files include server.xml, LdapUserRegistry.xml, ibm-team.keystore, localUserRegistry.xml, and appConfig.xml which are available in the JASInstall\wlp\usr\servers\jazzop directory.
To use Jazz Security Architecture single sign-on (SSO) authentication for existing deployments, it must first be enabled in all Jazz applications.
There are different procedures for enabling different types of applications for Jazz Security Architecture SSO. All applications do not need to be enabled at the same time. However, the login experience is not single sign-on until all applications are enabled.
For more information and related task topic, see Enabling applications for Jazz Security Architecture single sign-on.
If you are upgrading from release 7.0.1 or earlier to release 7.0.2 or later, and have associated EWM releases with global configurations, you must import release links into the GCM application as described in Adding release links in global configurations. If you do not import the links, incoming links from work items might not be displayed correctly in the IBM Engineering Requirements Management DOORS Next and IBM Engineering Test Management after upgrade.
Note: Importing release links is a post-install process.
If you are upgrading your Global Configuration Management server from version 6.0.1 and earlier, after the upgrade is complete you must reindex all data sources.
To ensure you have the latest project and process templates available on your server, after the upgrade is complete do the following steps to import the predefined templates.
To deploy the predefined project templates:
After a few moments a message is displayed that the predefined templates were deployed successfully.
application version 6.x did not contribute to LQE and LDX. However; during the upgrade, this application is converted to with AM Extension for application which supports Tracked Resource Set (TRS) specification. Therefore, you must register the corresponding TRS feeds as data sources in both LQE and LDX applications. If LQE/LDX are installed on a separate JTS from the CCM application, then perform the steps described in Connecting Lifecycle Query Engine to applications that use a different Jazz Team Server, else perform the steps described in Connecting Lifecycle Query Engine to applications that use the same Jazz Team Server.
If you do not register the corresponding TRS feeds, you will not be able to fetch details of OSLC links established between EWM artifacts owned by the upgraded server and artifacts owned by other EWM or ETM applications. Details of such OSLC links are fetched from LQE when generating JRS reports, where LDX is used to display data in Web Clients.
After you upgrade the Report Builder application, you must clear your browser cache including the cookies in order for the dashboard widgets to display correctly.
The CleanupUnusedIndexesVersionsTask must be disabled in this release of the Requirements Management application. If you are upgrading from an older version of the application, the CleanupUnusedIndexesVersionsTask might be disabled by default. Follow the steps in this task to ensure the CleanupUnusedIndexesVersionsTask is disabled.
If you installed a new version in your upgraded environment, you must complete the following steps before you can register the application with . If you upgraded to this release, the following steps are not required.
<application type="war" id="am" name="am" location="${server.config.dir}/apps/am.war">
<application-bnd>
<security-role name="JazzAdmins">
<group name="JazzAdmins" />
</security-role>
<security-role name="JazzProjectAdmins">
<group name="JazzProjectAdmins" />
</security-role>
<security-role name="JazzUsers">
<group name="JazzUsers" />
</security-role>
<security-role name="JazzGuests">
<group name="JazzGuests" />
</security-role>
</application-bnd>
</application>
Note: The line <application type="war" id="am" name="am" location="${server.config.dir}/apps/am.war"> contains the default application name. If during the installation you changed the application context root, replace am in the id, name, and am.war attributes accordingly.
The runstats utility in Db2 updates statistics about the physical characteristics of a table and the associated indexes. These characteristics include the number of records, the number of pages, and the average record length. The optimizer uses these statistics when determining access paths to the data. Call this utility when a table has had many updates or after reorganizing a table in a large scale Quality Management application database.
To run the runstats utility, open a Db2 command window and enter the following commands:
db2 connect to qm
db2 runstats on table "REPOSITORY"."VERSION" with distribution and detailed indexes all
db2 disconnect qm
To determine whether you need to enable database table partitioning, see Leveraging Database Partitioning in RQM for Data Growth on the Deployment wiki.
In version 6.0.6.1 and later, you can use the partitioning repotools command to partition a non-partitioned REPOSITORY.VERSIONREPOSITORY_VERSION<SchemaPrefix>_REPOSITORY.VERSIONRPSTR_VRSN table in a configuration-enabled system. The command partitions by range based on item types. Database table partitioning helps manage the performance, availability, and scalability of large amounts of data (millions of artifacts) in a repository. To use the partitioning features, you must install an Enterprise edition of a Db2 (or Advanced edition if using Db2 11.5)Db2 for z/OSDb2 for iOracleSQL Server database. Standard, Workgroup, Personal, or Express editions of the database, or the default Apache Derby® database, do not support partitioning. The command fails if the underlying database does not support partitioning.
Important: Back up the database before you use this command. After the successful completion of this command, database administrators should collect statistics for the REPOSITORY.VERSIONREPOSITORY_VERSION<SchemaPrefix>_REPOSITORY.VERSIONRPSTR_VRSN table and its indexes to help improve the performance of the database.
During data migration, the original table is duplicated until the end of the migration process, when the old table is dropped. Ensure that you have adequate disk space for data migration and for growing partitions after the initial copy and cleanup.
To enable the Quality Management application database table partitioning, open a command window and enter the following commands:
cd /server
./repotools-qm.sh -partitioning teamserver.properties=conf/qm/teamserver.properties enable
cd \server
repotools-qm.bat -partitioning teamserver.properties=conf\qm\teamserver.properties enable
For details about the partitioning repotools command, see Repository tools command to partition a database table.
If during the upgrade you encounter the following error message: CRJAZ1431E - The model COMPONENT_ID_IDX was illegally changed to be unique, you can use the SQL Server Management Studio to resolve the issue.
After the upgrade process is complete, use this checklist to determine whether each step was successful.
Verification task | More information | |
---|---|---|
Verify that these application configuration files are copied from previous installation to version :
Verify that the application configuration files are copied from previous configuration directory to version :
|
||
Verify that each teamserver.properties file contains this information:
|
||
Verify the application servers:
|
Deploying and starting the server | |
Check the server log files: Check the server log files to verify that they contain the post-upgrade information:
|
||
Regenerate your self-signed keystore: Your previous version self-signed certificate might not work after you upgrade because of the potential cypher changes in the new version. If you are not able to login to the server after the upgrade with the following error: ssl_error_no_cypher_overlap, you might just need to regenerate your self-signed keystore by using the newer JDK that is bundled with the product. | ||
Check the public URLs: If you upgraded , or any of the applications, make sure that the public URL on the application's status summary page is the same as the URL that was used in the previous version. | ||
Check the links on the Administration page: In a web browser, go to the Administration page of at https://hostname.example.com:port/jts/admin and make sure that no errors are displayed. | administrative web interface | |
Check the links on the application's Administration page: In a web browser, go to the Administration page of the application at https://hostname.example.com:port/application context root/admin and make sure that no errors are displayed.
For Report Builder, go to https://hostname.example.com:port/application context root/setup and make sure that no errors are displayed. For Lifecycle Query Engine, go to https://hostname.example.com:port/application context root/web/admin/home and make sure that no errors are displayed. |
Application administrative web interface | |
Run diagnostics on each server and verify that the diagnostics completed successfully:
It is also a good practice to run the database statistics after the upgrade to help with server performance. For more information about the database stats command, see the planning checklist table in this document. Note: Lifecycle Query Engine and Report Builder do not have a diagnostics section. |
||
Check users, licenses, and link artifacts:
|
Verifying users, licenses, and link artifacts | |
Check application artifacts:
|
Initialize the publish services |