Re: CMOD upgardes : v8.4.1 to v10.1 on Windows

[niclee]

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 :-)

Sorry for bringing up an old thread with a new post.

Thanks Alessandro for the steps, but I have some questions. I'm testing this approach right now.

Old machine:
Win2003, CMOD v8.4.0, DB2 v8.1.7

New machine:
Win2012R2, CMOD v10.1, DB2 v11.1.2

I installed latest DB2, and CMOD in the new server. I also exported both structure, and data from the old database.

Question:
1. Do I configure the new CMOD by creating a new instance? Creating a new instance will create a database.
2. If I don't create an instance in new CMOD but I create a new database with the same codepage/territory as the old database, how do I link a new CMOD instance with an existing database?

I also tried the steps below, and I couldn't start Library server with logon failure error:
1. Created new instance (which will create a database).
2. Dropped the database.
3. Created a new database with the same codepage/territory as the old database.
4. Created database structure using the result of db2look.
5. Loaded (db2move load) the data exported from old database.
6. Logon failure when starting CMOD Library server.
7. Changed CMOD instance credentials to follow the old CMOD's credentials but still login failure.


Thank you very much in advance!

[Justin Derrick]

This post was split from a previous topic, as it's an entirely new situation.

-JD.

[jsquizz]

I am hearing conflicting stories about upgrading to 10.1

Based on what I am CURRENTLY hearing...

You would have to go from 8.4.1, to 8.4.3, to 8.5, to 9.0, to 9.5, to 10.1...but who knows.

I did recently an 8.5 to 9.5 and the only reason we had to take a hop and do 9.0, was because we were using RDF

[niclee]

Thanks JD for splitting the thread.

Anyways, I think I upgraded successfully. The steps that I missed were recreation of db indexes using arsdb, and updating system log, and system load using arssyscr.

Below are the steps that I took:

• Install latest CMOD in new servers. Configure CMOD instance with the same name as the old instance. Ensure everything is working fine.
• Export data from old db using DB2MOVE EXPORT.
• Export db structure from old db using DB2LOOK (e.g. "db2look -d archive -e -o C:\temp\db2look-2nd.sql -l -x -f").
• Drop new db in new server.
• Create a new db with the same name, code page, and territory as the old db in the new server. DB2LOOK results does state the code page.
• Execute the DB2LOOK result, which is a SQL script, on the newly created db.
• Import exported data from old db, into new db using DB2MOVE LOAD.
• Perform CMOD upgrades using arsdb and arssyscr commands, which can be found in CMOD README.
• Both my environments using Cache storage. So I copied arscache1 folder from old server to new server.

Voila! New reports can be loaded. Old reports can be viewed.

I'll try these steps again to see if I missed any steps.

[Alessandro Perucchi]

I am hearing conflicting stories about upgrading to 10.1

Based on what I am CURRENTLY hearing...

You would have to go from 8.4.1, to 8.4.3, to 8.5, to 9.0, to 9.5, to 10.1...but who knows.

I did recently an 8.5 to 9.5 and the only reason we had to take a hop and do 9.0, was because we were using RDF

If you don't have RDF, then you can go directly from 8.4.1 -> 10.1 without stop.
The only reason you want to do a stop, is about the clients needs.
If you have a lot of old stuff accessing your CMOD (with arswww.cgi, old Java Program with old requirement on Java/...) then you might need to stop before 10.1 in order to resolve the client problem...
That's why at a customer I needed to stop with CMOD Server V9 and ODWEK 8.5, in order that he could upgrade its client legacy with new versions before going to V9.5.
That's the real reason to do a stop a one version for CMOD Server... and if some guys pretend that you must do (if you don't have RDF) a stop a each version, ... they don't know what they are talking about, and you must avoid them at all cost! (I speak from my experience here :-D)