Activating FL508 in a Three-Member Data Sharing Group
Subsystem DB2P is a three-member Db2 12 for z/OS data sharing group. All members are at function level FL504 and catalog level FL504. A vendor package for the new claims portal requires APPLCOMPAT V12R1M508, so the team plans to activate FL508 during a six-hour window. Maintenance and the fallback SPE are applied, and a sandbox group at FL508 passed application tests. Production contains 1,462 packages: 340 are bound at APPLCOMPAT V11R1, 1,120 at V12R1M500, and two vendor packages will be bound at V12R1M508 after activation. Rebinding all packages would take longer than the window. DDF transactions run continuously, and one batch job holds long-running read claims. The change board wants a step-by-step order, a list of packages that truly need rebinding, and an honest statement of what happens if a problem appears after activation.
1. What prerequisites and order should the team follow before and immediately after issuing `-ACTIVATE FUNCTION LEVEL(FL508)`? Include data sharing considerations.
Read the worked answer
Verify four things before the command: every member has the required PTFs and the fallback SPE; the catalog migration has brought the catalog to the level required for FL508; all members report FL504 and none is quiesced or in a restricted state; and no package is already bound at an APPLCOMPAT higher than FL508. Then issue -ACTIVATE FUNCTION LEVEL(FL508) from one member. In a data sharing group the function level is group-wide, but do not assume propagation: use DISPLAY GROUP DETAIL on every member and confirm that all report FL508 before allowing production work to resume. Immediately after activation, bind only the two vendor packages at V12R1M508 and run their acceptance tests. Keep the remaining packages at their existing APPLCOMPAT levels during the window. A common mistake is to treat activation as a package-rebind event; it is a subsystem change. The catalog migration and the activation command have different jobs, and activation cannot substitute for a missing catalog step.
2. Which packages must be rebound and which can remain at older APPLCOMPAT? Explain the risk of rebinding everything.
Read the worked answer
Only packages that need SQL or behavior introduced after FL504 must be rebound at the higher level. Here that means the two vendor packages that require V12R1M508. Packages bound at V11R1 or V12R1M500 remain valid after FL508 and continue to run with their package APPLCOMPAT, which is the point of the compatibility attribute: it lets old static SQL keep old semantics while the subsystem moves forward. Rebinding all 1,462 packages would take too long, but the bigger problem is that it would change access paths and SQL behavior for applications that did not need the change. That creates a broad regression surface during a narrow window. Dynamic SQL is different: its behavior is controlled by the CURRENT APPLICATION COMPATIBILITY special register or the package APPLCOMPAT for a dynamic package. If a package must move up, do it selectively and preferably into a separate collection so that a fallback to the old package is possible without rebinding everything again.
3. The change board asks for a rollback plan if a critical abend occurs two hours after activation. What can actually be undone, and what cannot?
Read the worked answer
Within Db2 12, a function level cannot be lowered. There is no -DEACTIVATE FUNCTION LEVEL that returns the group to FL504. The honest rollback statement is therefore: application-level remediation first, release-level fallback only as a separately planned procedure. If one package fails and it does not use FL508-only syntax, bind that package back to its earlier APPLCOMPAT and test it. If it depends on new FL508 behavior, fix or withdraw the application. A fallback SPE supports a fallback to the previous release, but that is not a same-release undo, requires a full fallback procedure, and must be proven before the window; it is not something to discover at 04:00. Do not promise that OPTHINT, a rebind, or a catalog restore will reverse function-level behavior. Before activation, confirm the exact fallback boundary with IBM support and test it in the sandbox group. After activation, protect the system with image copies, a clear application rollback list, and a decision point before the window closes.