Upgrading Maximo 7.5 to Maximo 7.6 (part 2)

Body

Continued from Upgrading Maximo 7.5 to Maximo 7.6 (part 1).

I have to admit my last blog post was not the most fascinating I've written. However, I made two important changes from the standard install that modify how I use the Configuration Tool. The first is that I installed Maximo 7.6 to a new directory rather than the existing Maximo 7.5 directory. The second is that I had already installed and migrated the profile with the MAXUPG server to WebSphere 8.5.5.3.

These changes mean that when I use the Config Tool, I will configure it (a) to point to an existing database and (b) will not have to configure the web application server, since it is already configured correctly.

First, launch the Config Tool, either directly from the last screen when installing Maximo 7.6, or by selecting Tivoli's process automation engine > Configuration Program from the Start Menu. (For those of you without a Start Menu, by default it is at C:\ibm\SMP\ConfigTool\ConfigUI.exe.)

Select Configure a New Deployment.

On this screen, I changed the database type to Oracle and entered the database hostname. I made sure that Create and Configure the database are not checked. In the Define the Deployment Manager Server Host Name, I leave it at WebSphere, enter the hostname of my WAS server, and check the Bypass WebSphere Validation box, which also changes the radio button to WebSphere is already configured.

On the Configure General Product Information, I entered the Worfklow administrator email address and SMTP server host name (not shown), though it is not required.

On this dialog, I enter the correct Oracle service name, and enter the schemaowner user name (maximo) and password. If I were creating a new database, I would enter a user with the SYSDBA system privilege (default SYS) and its password. Using maximo here will generate a non-fatal error when it comes time to configure the database, but you can ignore it.

On Configure Application Security, I enter the passwords for the three required product users. By doing so, I will not creating new users, since they already exist. I am providing the Config Tool with the correct required product user names and passwords, which it will put into install.properties.

Since I only use English (and wouldn't change the Base Language when upgrading the database), I click Next on this screen...

...and click Next on this one as well, because I'm keeping it simple.

On Apply Deployment Operations, I deselected Configure Application Server and Build the selected EAR files. My web application server name (MAXUPG) and application names (MAXUPG-MAXIMO and MAXUPG-MXIEHS) are different from the standard, MXServer/MAXIMO/MXIEHS. I will do those steps manually later. I click Finish, and away we go.

This error will pop up a couple of times. The error(shown in the Configuration View Console) is that the maximo schemaowner does not have the SYSDBA privilege. The Config Tool does not halt because of this error, since I am updating an existing database, not creating a new one. If I were creating a new database, I would use the SYS user anyway.

...some time passes... and the upgrade completes. The Config Tool displays this dialog box. What it means is that I did not configure the WAS server and build the EAR files. I will be doing that manually, so I click No, and exit out of the Configuration Tool.

How long did it take me to upgrade maxdemo? After making backups and taking snapshots, I started the Maximo 7.6 install at 11:39 AM. Updating the database maxdemo took 1 1/2 hours, from 3:36 PM to 4:56 PM. This time included a halt to correct an error with Oracle text indexes (they didn't exist), after which I restarted the deploying operation. The total time taken from install to upgrade completion was about 5 1/2 hours. In this case, the bottleneck was that my administrative workstation was in one place, the database server in another, and the WebSphere server in a third. I would say my setup is unusual, and some operations will take much less time when run locally (For example, in updatedb, the reportlabelloader task took 20 minutes when I ran it against my database in Austin. The same task took about 15 seconds when I ran it locally on a server. That server had everything on it: the administrative workstation, the database server, and the WebSphere server.

The next steps happen off screen. After updatedb is finished, I build the maximo (using buildmaximoearwas8.cmd) and maximoiehs EAR files manually. Then, I log into the WebSphere console. The MAXUPG web application server is already configured properly. The best practices recommendations we have published for Maximo 7.5 and WebSphere 7.0 also apply to Maximo 7.6 and WebSphere 8.5.5.3. The memory heap, generic JVM arguments and thread pools are already set, and I do not have to change them. So, I follow the steps we recommend when deploying new EAR files:
1. Uninstall the existing (7.5.0.6) applications
2. Install the new (7.6.0.0) applications
3. Clear the WebSphere cache files
4. Start the Maximo application server

and now, the moment of truth. Log into Maximo..

Looks different already! Check System Information:

And it's done! Maximo 6.2.3 to Maximo 7.6 in seven easy steps (6.2.3 > 6.2.8) -> (7.1.1.5 > 7.1.1.13) -> (7.5.0.0 > 7.5.0.6) -> 7.6.0.0.