Hi,
Did you really get that to work ??!!! I talk about point 2.
... yes I did, and I did other things like Convert DB2 -> Oracle and the reverse Oracle -> DB2. (things that are not officially supported by IBM, but the customer badly wanted because of some internal rules...)
Merging Object-Server with Library Server, Merging 2 CMOD together (merge of AG, or simply add new AG with all the AGID_NAME conversion...) and other things...
First of all I have 3102 Application Groups, it will take forever to do a rename of all the AGID_NAME.
Well in Unix, a simple script and you could automate it quite easily... but in z/OS, I have no clue...
How did you update the LOAD_ID , RESGRP, SEG_ID etc in ARSAG? Any miss will probably give you a lot of problem
You are right, I forgot to mention all these... and maybe other things too, I wanted just to give you a taste of the work you need to do in order make it happen. It is not easy, there are a lot of things to take care.
Since I have never done a downgrade like your case, I just took from memory the steps from several other projects, and try to glue them together and have this template of solution,
What about the ARSSYS table ?
Well ARSSYS is really a strange table for me. I had done some tests with these change of AGID_NAME, etc... and found that after a while CMOD in creating a new AG was using the same AGID_NAME as some other existing AG for some reasons.
I found out that this field in ARSSYS was the one which help CMOD to give me a new non used AGID_NAME....
That's only my experience, and I really don't know what is the truth behind my experience.
But since that time, I had no more problems.
I don't know if it's different i Multisystems, but I wouldn't dare do it your way :-D
Well I had no choice... the time schedule was very tide, and to make a migration (export-import) it was too long...
But you know I never did a downgrade. I am just saying that it should be possible, since you don't change the segment tables. You need to "correct" the system tables...
But this is not a solution that I would advice personally.
Especially because each case is different, and the work to do the downgrade could be different from one customer to another.
So my proposition was just a starting point, not THE solution to all problems!
I think I found a way of doing a 'downgrade' , if my way was to be done it wouldn't
be any problem even!!! if some data have been loaded in some ApplGroup and the LOAD_ID/SEG_ID for any
Appl Group it shouldn't be affected either.
When downgrading the tables:
1) Rename the tables that have been changed during upgrade,
IBM should be able to tell which tables have been changed ,
ex : ARSSYS --> ARS84SYS
2) Downgrade the code-base
3) Create the tables with the old layout.
4) Run some SQL-scripts(SPUFI/JOB) that does a load from ARS84SYS into ARSSYS where the columns
can be Casted to the old format, ex BigInt --> Integer, and the SQL can ignore new columns
sample:
"
INSERT INTO <CREATOR>.ARSSYS
( ID
,NAME
,CDID
,....... )
SELECT
ID
,NAME
,CDID
.........
FROM <CREATOR>.ARS84SYS;
"
5) Drop the indexes, and recreate them... should be possible to do by arsdb -???
6) If everything is okay after downgrade, the delete all ARS84-tables
Ok, I know that it will be impossible to do a cast if some BigInt has greater values than can be in
an Integer. But that can be checked before !!! any SQL would be run
Hmm ok, I didn't know that ARSYS has changed some of the table field data type... Well, it might be a solution yes.
Concerning the arsdb, yes, this is definitely a good idea:
arsdb -I <instance> -ev delete index
arsdb -I <instance> -rv recreate index
Otherwise, your solution might work. The only thing I can suggest you... BACKUP!!! in a way that you can go back and test again!
Good luck,
Alessandro
