Perform DB2 migration

What “Db2 migration” covers

People use “migration” for several related projects: moving from Db2 12 to Db2 13 (or another release pair), applying the continuous-delivery code that raises the code level, updating the catalog with CATMAINT, and activating a function level so new SQL and subsystem features become available. Premigration checkouts, fallback SPE application, coexistence rules, and application compatibility (APPLCOMPAT) planning are part of the same program of work.

This page focuses on the operational path: confirm readiness, tailor jobs with the installation CLIST or DSNTIJBC, activate intervening function levels when required, run CATMAINT for the target catalog level, verify catalog and directory health, then activate the target function level. It is not a substitute for IBM’s release-specific Premigration Checklist or for your site’s change-control package.

• Code level — maintenance and libraries the members are running
• Catalog level — structure of the Db2 catalog after CATMAINT
• Function level — capabilities activated with -ACTIVATE FUNCTION LEVEL
• Application compatibility — package APPLCOMPAT that governs SQL behavior for applications

Prerequisites

Read the Premigration Checklist and Installation and Migration Guide for your target release. For Db2 13, IBM requires completing premigration tasks and activating Db2 12 function level 510 before migrating. Apply required fallback SPEs and confirm every data sharing member can restart with the SPE before you proceed. DISPLAY GROUP should show code levels that support the target function level on every active member.

Authority is usually installation SYSADM or installation SYSOPR. Installation SYSOPR can install and migrate without broad access to user data, which is preferred when security policy allows it. Confirm RACF (or equivalent) permits the migration ID to run tailored jobs, issue ACTIVATE, and run CATMAINT. Schedule an outage or controlled window that covers image copies of catalog and directory, CATMAINT, possible REORG of AREO* catalog objects, CHECK INDEX on new catalog indexes, and activation.

Generate tailored JCL with the Db2 installation CLIST (INSTALL TYPE ACTIVATE or MIGRATE as your scenario requires) or the DSNTIJBC batch path. Save INPUT and OUTPUT members so you can reproduce the exact panel values. Take a documented image copy of catalog and directory (often DSNTIJIC) before irreversible catalog changes. Ensure fallback and coexistence are still possible until you intentionally activate the function level that ends coexistence—IBM documents that activating function level 500 or higher can permanently end fallback to the prior release.

Step 1 — Verify code level and group readiness

Issue DISPLAY GROUP and record code level, catalog level, highest activated function level, and member status. In data sharing, every active member must be at a code level that supports the target. Do not start CATMAINT for a higher catalog level if any member might still need to run older code that cannot tolerate those catalog changes.

Optionally issue ACTIVATE FUNCTION LEVEL with the TEST option for the target level. TEST reports eligibility without activating. Message output explains whether the catalog level is high enough and whether any member or SPE gap blocks activation. DISPLAY GROUP is also useful for inspecting supported levels without risking an accidental activate.

1
2
3
4
-DISPLAY GROUP DETAIL
 
-ACTIVATE FUNCTION LEVEL (V13R1M500) TEST
/* Review readiness messages before any non-TEST ACTIVATE */

Step 2 — Tailor migration and activation jobs

Run the installation CLIST in the mode that matches your project. For function-level activation on an already-migrated release, INSTALL TYPE ACTIVATE with current and TARGET FUNCTION LEVEL on DSNTIP00 is typical. The CLIST edits ACTIVATE into DSNTIJAF and CATMAINT LEVEL into DSNTIJTC. For a release migration, follow the generated migration job stream in IBM’s guide—premigration jobs, library switches, and early activate steps differ by release.

Review every tailored job before submit. Confirm subsystem name, data sharing group settings, SMS classes, work data sets, and the exact function-level string (for example V13R1M5nn). In data sharing, CATMAINT and ACTIVATE have group scope—run them on one originating member only, not once per member.

Step 3 — Activate required intermediate levels and run CATMAINT

Some paths require activating an intermediate function level before CATMAINT for a higher target. IBM’s Db2 12 and Db2 13 procedures describe jobs such as DSNTIJA0 / DSNTIJA1 for early levels, then DSNTIJTC for CATMAINT. Run CATMAINT only when you are committed to remaining on a code level that tolerates the new catalog. Do not attempt to start Db2 at a lower code level after any part of a higher-level CATMAINT completes.

If CATMAINT places altered catalog objects in REORG-pending advisory (AREO*), REORG those objects as the guide directs. Run CHECK INDEX (often via a generated DSNTIJX2-style job) for new catalog and directory indexes. Resolve utility failures before activation; a half-applied catalog change with unresolved advisory states is a poor place to pause without a documented recovery plan.

1
2
3
4
5
6
// Illustrative CATMAINT control (exact LEVEL comes from tailored DSNTIJTC)
CATMAINT UPDATE
  LEVEL V13R1M501
 
// After catalog change, image-copy catalog/directory per site procedure
// Then activate only when TEST and checks are clean

Step 4 — Activate the target function level

Re-run ACTIVATE with TEST if anything changed since the last readiness check. When eligible, run the tailored DSNTIJAF job or issue ACTIVATE FUNCTION LEVEL without TEST. Successful activation makes that function level and lower levels available. Record the DSN9022I-style completion messages and the new DISPLAY GROUP output in the change ticket.

Remember that activating certain function levels is a one-way door for coexistence and fallback. Do not activate until operations, application teams, and management accept that the prior release is no longer a return path. Separately plan APPLCOMPAT raises for packages; activating a subsystem function level does not automatically move every package to the newest SQL behavior.

1
2
3
-ACTIVATE FUNCTION LEVEL (V13R1M501) TEST
-ACTIVATE FUNCTION LEVEL (V13R1M501)
-DISPLAY GROUP DETAIL

Verify results

DISPLAY GROUP must show the expected function level, catalog level, and code level on all members. Confirm CATMAINT and activation jobs ended with the return codes your procedure allows. Verify catalog and directory image copies completed, CHECK INDEX jobs were clean, and no unexpected restrictive states remain on DSNDB01 or DSNDB06 spaces.

Smoke-test critical applications, DDF connectivity, stored procedures, and utilities that your premigration plan listed as risk items. Validate that monitoring and recovery tooling understand the new release. Only then close the migration window and schedule phased APPLCOMPAT or new-function adoption for applications.

• DISPLAY GROUP matches the target function and catalog levels
• CATMAINT, REORG, and CHECK INDEX evidence attached to the ticket
• Catalog/directory copies taken before and after as required
• Fallback/coexistence decision explicitly recorded
• Application smoke tests signed off

Common errors

Activating without TEST and discovering a member still at the wrong code level is a preventable failure—always DISPLAY GROUP and TEST first. Running CATMAINT while still entertaining fallback to a code level that cannot tolerate the catalog is a serious operational risk. Issuing ACTIVATE or CATMAINT on every data sharing member instead of once for the group creates confusion and duplicate work.

Skipping premigration function-level requirements (such as Db2 12 FL 510 before Db2 13) causes migration jobs to fail or leave the group in an unsupported mix. Ignoring AREO* catalog objects after CATMAINT leads to avoidable performance and maintenance issues. Raising APPLCOMPAT broadly on day one without regression testing can surface SQL incompatibilities that are unrelated to the subsystem activate itself—keep those workstreams distinct.

Authority errors (missing installation SYSOPR or SYSADM), wrong tailored member names, and incomplete image-copy coverage of catalog and directory are frequent change-ticket findings. Treat migration as a rehearsal-friendly procedure: practice on a clone or sandbox subsystem with the same CLIST inputs whenever your site allows it.