Hello bblunt,
Wow... what a lots of work.... really lots of work.... *sigh*.
I've performed such migration, and what we do it basically db2move from the database A to database B. This is much faster, and it takes a lot less time.
Ok, let's play your way by answering your question first. Then I will explain how I would have done it.
Is CMOD designed to allow us to run an ARSDOC GET on CMOD 7.1.2.8 and run ARSLOAD on a CMOD 8.5.0.x system to correctly load the data pulled from the 7.1.2.8 system?
Yes without problems.
Is CMOD designed to allow us to run an ARSDOC GET on CMOD 7.1.2.8 and run ARSLOAD on CMOD 9.0.x system to correctly load the data pulled from the 7.1.2.8 system?
Never tried... I'm not 100%, since the way CMOD is build, they have done a lot of work behind the scene, so it means that a arsload might not work for such a difference of version...
If this ARSDOC GET/ARSLOAD procedure should work for either version, should we move to CMOD 8.5 or CMOD 9.0?
I would say directly to V9.0.0.2
If we use batch ARSDOC GET(old CMOD) and ARSLOAD(new CMOD) procedures, how can we ensure documents loaded into the new CMOD age off on the correct dates? Basically, we?ll be getting 6, 5, 4, 3, 2, 1, etc... year old documents from the old system and we want the new system to recognize them as 6, 5, 4, 3, 2, 1, etc... year old documents when they?re loaded.
It will not be a problem, since the document's expiration date is in a field, and it will be also exported. Meaning that CMOD will know that such date is already 6 years old (for example) and needs to be kept only 4 years instead of 10 years (in the case you want to keep your data only 10 years).
Now, depending on the volume of data we are speaking here, and where are the data stored in TSM (Tapes or not). I would suggest that kind of migration:
Plan B:
1) export the database from Source with the command db2move
2) do a db2look in order to have the layout of all the tables and tablespace behind.
3) check with a DBA is the old layout is still ok for the new system, if not adapt the output of db2look to be in sync with the new system.
4) Recreate the whole CMOD database layout with the correct db2look output (corrected in 3) (be careful with the database codepage)
5) LOAD the database to the Target system with the command db2move
At this point, you have a database 7.1.2.8 in your new environment, you will need to reorganize all your table manually, and perform the CMOD upgrade from 7.1.2.8 -> V8.5 or V9
After the migration you have in a few hours a running CMOD library server without any objects. The time to perform it is really dependent on the volume of the DB2 export.
You can at this point, begin to remove the different storage node in your environment, to recreate a storage node in the cache for each of your storage set.
You will need to keep the new internal ID of your new node for each storage set that you have used, in order to be able to modify all the segment tables in CMOD. (with a update table for each segment).
Depending on how big is your database, and the CMOD data model, you can do it normally in 1 or 2 days.
Then comes the big work. Export all the data from TSM to disk.
Basically you will use the command "arsadmin retrieve" on the source environment, and arsadmin "store" in the new environment.
For that you will need to extract the doc_name in your segment tables, for each application group, and when you have them, just reinject them in the cache of the target system.
I've been quite simple in my explanation, but you need to know very well the product, and then you will gain a lot of time for your migration. But there are also a lot of space to make mistake if one is not careful enough.
Your solution will work, but it will be the slowest and safest method.
I'm maybe more like a stuntman sometimes!!! :-D
Sincerely yours,
Alessandro
