In RM 5.0, the data is no longer stored on the JTS server. Rather, it is stored with the RM server itself. The movement of the data from JTS to RM has caused significant changes and several additional steps for the 4.x to 5.0 upgrade procedure.
The database administrator must first create a copy of the JTS database to be the new RM database. After that, use the interactive upgrade guide to create a customized set of instructions to follow during upgrade. Most of the time, this will use the
rm_upgrade.[sh|bat]
wrapper script to guide CLM administrators through the upgrade. However, in some cases (distributed without a shared drive or windows with DBCS code page) the script will create a sequence of
RepoTools commands that doesn’t use the wrapper script.
The RM upgrade script (rm_upgrade.[sh|bat]) includes the following steps:
- updateConfigurationFiles*
- addTables**
- finalizeApplicationMigration (RM)
- finalizeApplicationMigration (JTS)
- reindex
- updateProjectBacklinks** (When RM offline) or updateProjectBacklinksOnline** (When RM online)
* Requires user interaction to specify new JDBC database connection, rest of prompts are confirmations
** Requires user interaction for confirmation prompts only
Recommendations
- Use the Interactive Upgrade Guide to generate the upgrade instructions for your deployment
- Use a staging area with copies of your data to run through the upgrade and create time estimates for your particular upgrade
- Backup your CLM databases prior to the upgrade - the copy of the JTS database to the new RM database can be done during this same downtime
- Have the following pieces of information handy before starting the upgrade:
- the install directory or directories of your CLM 4.X applications
- the install directory of your new JTS 5.0 (possibly via mount if remote)
- JDBC connection syntax for the new RM database
- JDBC connection password for the new RM database
- RM public URL of your deployment
- Upgrade JTS, then RM, then the other CLM applications
Common problems
Editor (to verify properties) doesn't work on Linux
During the
updateConfigurationFiles step the JTS and RM
teamserver.properties
files are opened in an editor for users to inspect or update. This does not work on Linux.
See
defect 87659
Workaround: open files manually.
Reindex step
The
reindex step is not required and, if skipped, the indices will be built once the RM server is brought online, we recommend running the reindex to complete the upgrade and improve performance once the server is brought online.
If running the
rm_upgrade.[bat|sh]
script, there is no progress indicator displayed in the command window during the reindex (See
defect 87722). There are progress updates written to the
rm_upgrade_rmupgrade.log
file in the server directory.
If running the reindex step manually, the progress indicator will appear in the command window.
Resuming where you left off from a failed step
If the upgrade script fails during any of the steps you are not able to resume from the point of failure. You can re-run the upgrade script from the beginning and skip the steps that succeeded. (See defect
defect 87732).
Upgrading multiple apps at the same time
While it is possible to upgrade all the applications in a distributed CLM environment at the same time it is not recommended. The first portion of the RM upgrade requires other applications to be offline. Then for the
updateProjectBacklinks step the applications need to be brought online. Exactly when each of the applications should be upgraded during this process can be confusing and it is not fully documented in the IUG yet. (See
defect 314856 ).
The other applications do not have to be at 5.0 yet in order to complete the
updateProjectBacklinks step.
It is best to fully complete the JTS upgrade then complete the RM upgrade separately from the CCM and QM upgrades. You can still perform the upgrades in any order after the JTS upgrade. It's just less confusing to perform the upgrades separately.
Script execution directory
When using the
rm_upgrade.[sh|bat]
script, be sure to run it from the
/server
directory, specifying the path to the script
C:\Program Files\IBM\JazzTeamServer\server>upgrade\rm\rm_upgrade.bat
Ordering of upgrades
Be sure to run JTS upgrade BEFORE running RM upgrade. If you run RM Upgrade first, you may run into the following problem:
2014-05-07 15:17:59,432 Repo Tools
2014-05-07 15:17:59,432 java.version=1.6.0
2014-05-07 15:17:59,432 java.runtime.version=pwa6460sr15fp1-20140110_01 (SR15 FP1)
2014-05-07 15:17:59,448 Provisioning using "c:\Program Files\IBM\JazzTeamServer\server\upgrade\rm\..\..\conf\rm\provision_profiles".
2014-05-07 15:17:59,479 repotools-rm -addTables
2014-05-07 15:17:59,479 Rational Requirements Composer, Version 5.0 (RMS5.0-I20140502_1820)
Jazz Foundation - Core Libraries, Version 5.0 (RJF-I20140502-1642)
2014-05-07 15:17:59,526
To submit questions about issues, go to the Jazz.net forum at https://jazz.net/forum.
To find more information about a message, see the CLM Messages Information Center at
https://jazz.net/help-dev/CLMErrorMessages/index.jsp.
2014-05-07 15:17:59,526 CRJAZ1363I Loading the configuration from "file:conf/rm/teamserver.properties".
2014-05-07 15:18:01,245 Rational Requirements Composer is starting.
Rational Requirements Composer, Version 5.0 (RMS5.0-I20140502_1820)
Jazz Foundation - Core Libraries, Version 5.0 (RJF-I20140502-1642)
2014-05-07 15:18:01,245 CRRRS9938I Repository state is: INITIALIZING
2014-05-07 15:18:01,370 CRJAZ1778I This server is configured as an application.
2014-05-07 15:18:01,729 CRJAZ2558I Setting the local server rename state to false and the openServerDescriptionServiceTemporarily state to false.
2014-05-07 15:18:02,885 CRJAZ1365I The server is attempting to connect to the following database: "conf/rm/derby/repositoryDB"
2014-05-07 15:18:04,214 CRJAZ1364I The connection to the following database was successful:
Db Product Name: Apache Derby
Db Product Version: 10.8.2.3 - (1212722)
Db URL: jdbc:derby:conf/rm/derby/repositoryDB;create=true
Jdbc Driver Name: Apache Derby Embedded JDBC Driver
Jdbc Driver Version: 10.8.2.3 - (1212722)
2014-05-07 15:18:05,667 CRJAZ1970I The application is configured with:
Public URI: "https://minvm.ibm.com:9443/rm"
Jazz Team Server location: "https://minvm.ibm.com:9443/jts/"
2014-05-07 15:18:06,073 CRJAZ2523I Setting the global server rename state to false and the validation state to false.
2014-05-07 15:18:09,854 CRJAZ2105I Checking for a running server...
2014-05-07 15:18:13,542 CRJAZ1886E The configured database lock id does not match the lock id in the database. This can happen if two applications or Jazz Team Servers are trying to access the same set of tables, or if the lock id was overwritten or lost in the teamserver.properties configuration file. Check the server configuration and the database connection spec and ensure they are correct. To recover from an emergency lockout, the lock can be reset using the 'repotools-rm -resetRepoLockId' command.
com.ibm.team.repository.common.TeamRepositoryException: CRJAZ1886E The configured database lock id does not match the lock id in the database. This can happen if two applications or Jazz Team Servers are trying to access the same set of tables, or if the lock id was overwritten or lost in the teamserver.properties configuration file. Check the server configuration and the database connection spec and ensure they are correct. To recover from an emergency lockout, the lock can be reset using the 'repotools-rm -resetRepoLockId' command.
at com.ibm.team.repotools.commands.local.internal.AddTablesCommand.execute(AddTablesCommand.java:153)
at com.ibm.team.repotools.command.AbstractCommand.execute(AbstractCommand.java:67)
at com.ibm.team.repotools.rcp.internal.RepositoryToolsApplication.run(RepositoryToolsApplication.java:816)
at com.ibm.team.repotools.rcp.internal.RepositoryToolsApplication.start(RepositoryToolsApplication.java:891)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
at org.eclipse.equinox.launcher.Main.run(Main.java:1408)
at org.eclipse.equinox.launcher.Main.main(Main.java:1384)
Caused by: com.ibm.team.repository.common.TeamRepositoryException: Server lock id value [none] and database lock id _2nasMNXuEeONBLWylHGefg do not match for database jdbc:derby:c:/PROGRA~1/IBM/JAZZTE~1/server/conf/rm/derby/repositoryDB. Use the 'repotools-rm -resetRepoLockId' command to remove the DB lockID, after ensuring this DB is not used by another JTS or application.
at com.ibm.team.repository.service.internal.db.util.RepoLockIdUtil.checkServerToSchemaLockAndReturn(RepoLockIdUtil.java:207)
at com.ibm.team.repository.service.internal.db.util.RepoLockIdUtil.checkServerToSchemaLockAndReturn(RepoLockIdUtil.java:161)
at com.ibm.team.repository.service.internal.db.util.RepoLockIdUtil.checkServerToSchemaLock(RepoLockIdUtil.java:141)
at com.ibm.team.repotools.commands.local.LocalRepositoryCommand.checkIfRepoLockIdValid(LocalRepositoryCommand.java:228)
at com.ibm.team.repotools.commands.local.internal.AddTablesCommand.execute(AddTablesCommand.java:149)
... 16 more
2014-05-07 15:18:13,542 CRJAZ1728E A Repository Tools error occurred. For more information, see this log file: c:\Program Files\IBM\JazzTeamServer\server\repotools-rm_addTables.log
2014-05-07 15:18:13,682 CRRRS4120I Rational DOORS Next Generation Fronting Service bundle stopped
This is because the file you used was a brand new JTS file, and it didn’t have the required properties. To fix this, upgrade JTS first, then rerun the upgrade script.
Similarly named commands
There are two steps that execute similarly named repotools commands.
repotools-rm.bat -finalizeApplicationMigration
repotools-jts.bat -finalizeApplicationMigration checkOauthDomain=true applicationId=RM-application-id newPublicUrl=NEW_RM_PUBLIC_URL
Verify arguments for RM finalizeApplicationMigration command
Do
not specify arguments
checkOauthDomain=true
or
applicationId=RM-application-id
or
newPublicUrl=NEW_RM_PUBLIC_URL
when executing the RM
finalizeApplicationMigration repotools command. Undetermined behavior will result.
Verify arguments for typos
Check the
newPublicUrl
argument for typos. If you notice that ‘unresolved context’ appears when viewing RM projects in the
/admin
page, check the parameters to this command. They are not verified and will be used as is.
Verify arguments for JTS finalizeApplicationMigration command
If you do not specify
checkOauthDomain
or set
checkOauthDomain=false
, then you MAY have problems creating new projects from the
/admin
page.
Use the appropriate Oracle DB version
You will get an error during
addTables if you do not use the appriopriate Oracle DB2 version driver and database.
External links:
Additional contributors: