CMOD upgardes : 8.4.1 to 9.5 on AIX

[liakkuan]

Hi,

I have a customer who has CMOD ver 8.4.1 on IBM PSeries, AIX 5.3, DB2 9.1, TSM 5.4 (All in one machine), and would like to upgrades CMOD 9.5 on a new hardware with P Series/AIX 7.X, DB2 10.X and TSM 7.X.

Would like to know what are the application upgrade approach available for this environment? Would like to find out as well how to migrates the data in DB2, content in disk storage and TSM. May I know does customer need to perform data migration (as in export-import) for the upgrades?

[Justin Derrick]

If you're moving to new hardware, build the system from scratch, and try to move the data over.  Repeat this process until you're confident that you can do it reliably.  Once you can do it completely, test it for a few weeks to find out where the problems are.

You've got a lot of issues with old software -- I don't think you can go from TSM 5.4 to 7.1 directly.  You might want to install TSM 5.5 on the new server, restore the backup from 5.4, then apply the migration patches (5.5.6 was the last version I've seen) and then do the upgrade on the new hardware.

And again, I'm not sure you can go from DB2 9.1 to 10.1 in one step.

What you're asking for would be simple if the customer had kept current on their patch levels.  Make sure they remember that in the future!

-JD.

[Alessandro Perucchi]

My suggestion would be the following (in the same line as Justin:

For the CMOD Server side:
- Install the new server with all the software
- Configure everything on the new server, so you could just start from scratch, in order to test that everything works as expected
- Export the DB2 V9.1 (with the command "db2move export")
- Export the db structure (with a db2look)
- Create a DB with the same codepage as the old one
- Play the new db structure created on with the db2look command (you can change some tablespace/add new ones/etc... but don't change the table structure at all or the indexes)
- Import the export from previous step with a "db2move load"
- Do the CMOD upgrade from V8.4.X to V9.5.X

For the TSM Server side:
- Install the new server with all the software
- Configure everything on the new server, so you could just start from scratch, in order to test that everything works as expected
- Upgrade to the latest level of TSM V5.5 -> V5.5.7 (this is a MUST, you cannot do the next step without being in V5.5 latest FP).
- do a server to server export procedure from V5.5.7 to V7.1.1.1+

And that should be it... there is really nothing special, I've done it countless of time, even going from DB2 V8.1 to V10.5 for a customer.

As Justin said, if the customer keeps current on the patch level, that would be much simpler :-)

[jsquizz]

And again, I'm not sure you can go from DB2 9.1 to 10.1 in one step.

Curious about this as I am in the beginning of planning a similar upgrade, though a slightly newer version of DB2. (9.5)

[Justin Derrick]

In my experience, x-2 (two previous versions) is always supported -- anything more than that is a gamble. 

So, 9.5 to 10.1 is X-2 (10.1 -> 9.7 -> 9.5) and should definitely be supported.

But what liakkuan wants to do is x-4 -- 9.1 ->10.5, skipping over 9.5 and 9.7 and 10.1... 

It might be possible to upgrade v9.1 to a fixpack level that's functionally equivalent to v9.5 -- which is closer to what you want...  But I would imagine it's unsupported and undocumented.

[Alessandro Perucchi]

In my experience, x-2 (two previous versions) is always supported -- anything more than that is a gamble. 

So, 9.5 to 10.1 is X-2 (10.1 -> 9.7 -> 9.5) and should definitely be supported.

But what liakkuan wants to do is x-4 -- 9.1 ->10.5, skipping over 9.5 and 9.7 and 10.1... 

It might be possible to upgrade v9.1 to a fixpack level that's functionally equivalent to v9.5 -- which is closer to what you want...  But I would imagine it's unsupported and undocumented.

Like I said, if liakkuan wants to change server, then the most "easy" way to do it is:

a) install the new DB2 version 10.5 latest fix pack
b) create an db2 instance
c) create a database with exactly the same codepage/territory as the original DB
d) export all the CMOD tables from the original DB with db2move export
e) get all the structure of the original db with db2look
f) apply the structure from point e) to the new DB (you might need to modify some things, like the path, etc... from the output of db2look)
g) load all the tables to the new DB with the command "db2move load"

and you can really go from DB2 V8.X to V10 without any problems.

Of course, if you want to install the old version in the new server, restore the whole database with the old version, then do the official upgrade on the instance, then yes, you might need to do some middle upgrade in between...
I've never done that, since I want to keep it simple :-)

Now YMMV... but in any cases, this needs to be tested tested tested, with any method, the "normal" db2 upgrade, or the db2move method.
BTW, I've done once a migration from CMOD DB2 on Windows, to a CMOD using Linux... and this method was the only one that was working. And now 3-4 years, it is still running, and I have performed an upgrade from V8.5 to V9.5 without a single problem.

[jsquizz]

In my experience, x-2 (two previous versions) is always supported -- anything more than that is a gamble. 

So, 9.5 to 10.1 is X-2 (10.1 -> 9.7 -> 9.5) and should definitely be supported.

But what liakkuan wants to do is x-4 -- 9.1 ->10.5, skipping over 9.5 and 9.7 and 10.1... 

It might be possible to upgrade v9.1 to a fixpack level that's functionally equivalent to v9.5 -- which is closer to what you want...  But I would imagine it's unsupported and undocumented.

Like I said, if liakkuan wants to change server, then the most "easy" way to do it is:

a) install the new DB2 version 10.5 latest fix pack
b) create an db2 instance
c) create a database with exactly the same codepage/territory as the original DB
d) export all the CMOD tables from the original DB with db2move export
e) get all the structure of the original db with db2look
f) apply the structure from point e) to the new DB (you might need to modify some things, like the path, etc... from the output of db2look)
g) load all the tables to the new DB with the command "db2move load"

and you can really go from DB2 V8.X to V10 without any problems.

Of course, if you want to install the old version in the new server, restore the whole database with the old version, then do the official upgrade on the instance, then yes, you might need to do some middle upgrade in between...
I've never done that, since I want to keep it simple :-)

Now YMMV... but in any cases, this needs to be tested tested tested, with any method, the "normal" db2 upgrade, or the db2move method.
BTW, I've done once a migration from CMOD DB2 on Windows, to a CMOD using Linux... and this method was the only one that was working. And now 3-4 years, it is still running, and I have performed an upgrade from V8.5 to V9.5 without a single problem.

So a 9.5 to 10.5 upgrade should be fine, and not require another "hop" to 9.7 ?

[Justin Derrick]

So a 9.5 to 10.5 upgrade should be fine, and not require another "hop" to 9.7 ?

You wouldn't want to do this for an in-place upgrade.  Only for a hardware migration.  I'd recommend the normal path, installing the new version of DB2, and trying to migrate the instance.

-JD.

[Alessandro Perucchi]

Justin,
you are 100% right concerning the in-place upgrade.
Since the original question said that they will go to a new hardware, then the db2move is the way I recommend.