Top Tip for Avoiding Conversion Mode Outage

Are you looking forward to using those lovely new DB2 10 for z/OS features, but dreading having to schedule the outage needed to get to Conversion Mode? Although a DB2 data sharing group can theoretically be upgraded to the new release with no loss of availability, certain processes such as DDL and BIND can suffer workload delays or timeouts during the CM catalog migration process (aka DSNTIJTC), so many sites bite the bullet and book an application outage to accomplish this.

Here’s a neat trick which has been successfully used by one of our customers to avoid these issues. What they do is to identify a point in time prior to their new release CM target date where there is already an application outage booked for another reason. During this outage, they migrate to CM (thereby upgrading the catalog) then immediately fallback to the old release. This process leaves the catalog at the new release level after fallback, so when they are ready to go to CM for real there is no DSNTIJTC to run and therefore no loss of availability.

Lots of caveats and cautions to take into account if you decide to go down this route, but if you plan it properly there are some nice upsides: someone else takes the “blame” for the outage and your real move to CM is both quicker and less complex.