move a CMOD Instance to another lpar

[eefgoes]

Has anyone experience with moving a CMOD Instance from one lpar to another lpar?

[demaya]

Good Morning,

not on Z but on Power... what infos do you need?

Cheers

[hakan_carlberg]

Hi

As long as you have the same values in ars.ini/ars.cfg/ars.cache and can 'move'(if you don't have it mounted SYSPLEX-wide) your ars.cache-directory then I don't see any problem with it. Don't forget the load-modules.

Regards
/H Carlberg

[eefgoes]

Hakan,

It is not that simple.

First of all we are not using cache-storage. Everything is in DB2-VSAM and VTS.

You cannot move the DB2-VSAM's from 1 lpar to another. We have to cope with Namingconventions. DB2-Db does not connect with the DB2 subsystem on the target lpar. CMOD generates its DB2 table dynamically. Internal values correspond with the external DSNAMEs. And so on.

Second problem is how to move the OAM Administration (also within DB2) to the target lpar.

The data is AFP-data. How about the AFP-resources when not stored with the data or just with the data.

Namingconventions also aplly to the userid's. You have to change this within CMOD and RACF.

Of course we can unload all CMOD data stored. In our situation it's 15Tb compressed - ~150 Tb uncompressed! Talking about miljons LOADID's and/or Biljons of indexes. Our support team had to unload a small peace of the data in the past. It took 8 months to unload this data. We foresee many years to unload our total data.

So these are the problem we see now.....

[hakan_carlberg]

Hi

We don't use cache either, but when we installed OD for the first time and brought it up,
It used the cache-storage before we changed to OAM. So I would like to bring the cache-storage as well.
And, unfortunatly, there was some error when we applied an PTF, so some data(from SYSLOG) we're stored on the
cache-system. I don't want to loose that.

I thought, because as I answered the way I did,that you just wanted to move the OD-server, but had the same DB2-system up and running on the other 'side'.

It sound's that you want to do something that I even hadn't thought about, move to another lpar, that's not connected to the same SYSPLEX ?

regards
/H Carlberg

[brianmurray]

We've started looking at the same problem.   We're moving a portion of CMOD/OAM from one LPAR to another.  With all of the migration documentation from ibm.com, I was surprised to see nothing that fit the bill.

Here's what I'm thinking.  First, this document describes migrating the OAM data.  I can't tell you if this fits your configuration but take it as food for thought:  http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.idao200%2Fdgt2o280.htm

I think the key to this work is the referenced DB2 utilities to back up and restore large amounts of data.

Once the objects are copied over to the new system, the problem becomes OnDemand.   I'm considering a similar approach using DB2 utilities.   My thoughts:  1)  export the OnDemand configuration to the new system.  2)  Copy over all of the index tables using DB2 utilities.   3)  Manually update or copy over the configuration tables like arsseq and arsag.  The end goal is that when a user retrieves a document or loads the next document, the data tables are in the same state that they were on the old system. 

OnDemand index tables are dynamically defined, but the dynamic definitions come from the configuration tables, so the settings have to be the same.

Good luck.  If you make any progress, please share.

[leodejong]

Hi eef,

We here at Rabo did this a few years ago. But we are DASD only no opticals.
I have followed the following scenario:
First you have to do all the OAM set-up steps from the OAM PISA (Parmlib, STC's RACF)
Then we have decided to use a dedicated DB2 for OAM/Ondemand, so i created a new DB2 and ran all the OAM setup's until i was able to store and retrieve an OAM objects on the new system.
Also installed a new Ondemand instance on the new LPAR. Verified that it worked. So now i considered the receiving LPAR was ready to receive the data.
Then i stopped DB2 on source LPAR, dumped all the DB@ catalog,OAM and Ondemand VSAM datasets with ADRDSSU on tape. But if you have shared DASD, you can use that.
On the target LPAR, i also stopped the new DB2 and deleted all the datasets (catalog, OAM and Ondemand tablespaces and IC).
Restore datasets from source.
I have decided for a DB2 coldstart, so i recreated and inited the BSDS and logs. Set a conditionalrestart record with the RBA from the source DB2.
Started DB2 in access(maint), replied the coldstart reply. If the VSAM datasets have a different high-level-qualifier, and you have DB2 V9+, you can run REPAIR CHANGE VCAT (or something similar) .
If applicable change any authorisations in DB2 from the userid which are used on the source lpar to the one used on the target LPAR.
Do a IDCAMS DEFINE NONVSAM (NAME(collection) COLLECTION RECATALOG) for every collection name in the OAMADMIN.CBR_COLLECTION_TBL.
If testing, allways go from bottom to top. First test if OAM works (TSO OSREQ STORE/RETRIEVE), then

Hope this is complete. It was some time ago.
Leo

[eefgoes]

Leo,

Thanks for the info/scenario. We will see if our situation maps with yours at Rabobank.

Eef