Author Topic: How to make fallback from upgrade?  (Read 12667 times)

ewirtz

  • Full Member
  • ***
  • Posts: 134
    • View Profile
Re: How to make fallback from upgrade?
« Reply #30 on: April 19, 2017, 01:07:06 AM »
Hi scottnys,
you can avoid duplicate loadids by manipulating arsag. You can avoid segment splits by manipulate arsseg. The needed SQL have been accepted by IBM of course for a special migration.  Being aware of this a DB2 fallback is possible and you can load reports that are lost by this fallback. After the final migration you delete the reports from OAM with arsadmin unload. These unloads are accepted by ARSSOCKD (even if no knowledge them).
It's still true that this is not our task. But it works. The main idea of the technique is to separate the migration / fallback process from the details of the changes between version (a) and (b). Preconditions are
a) the same documents can be loaded / unloaded with version(a) and version (b)
b) going back to the old content of the database. (here the kind of table changes have to be observed for a proper reconstruction)

regards

Egon

hakan_carlberg

  • Jr. Member
  • **
  • Posts: 83
    • View Profile
Re: How to make fallback from upgrade?
« Reply #31 on: April 19, 2017, 07:50:24 AM »
Hi everybody

I know, I'm stubborn...

But..
".. if you switch to new functions mode after a DB2 migration you cannot do a fallback afterwards.."
Yes, that's true when you've switched to NFM..
but it's not a big bang(Nice Tv-show though), and you don't have to mess around with a bunch unload/load and other stuff.
And as long that you're in CM-mode you can always return, you don't switch to NFM until you're sure it will work.
Since going to NFM, you can return to CM*, and that code will probably work for you.

Still, let IBM fix this fallback stuff, it shouldn't be that hard to fix.
And it is a mess(At least I think that)

Regards
/H Carlberg