IBM Data Platform Ideas Portal for Customers


This portal is to open public enhancement requests against products and services offered by the IBM Data Platform organization. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:


Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,


Post your ideas

Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,

  1. Post an idea

  2. Upvote ideas that matter most to you

  3. Get feedback from the IBM team to refine your idea


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

IBM Employees should enter Ideas at https://ideas.ibm.com



Add a new idea Subscribe
Status Under review
Workspace Db2 for z/OS
Created by Guest
Created on Jul 2, 2026

RELATED IDEAS

Support for Fallback to Prior Function Levels from FL100 and Relaxation of Migration Requirements

The introduction of Continuous Delivery starting with Db2 12 has provided significant benefits in terms of rapid feature adoption. However, a distinct segment of enterprise users prioritizes absolute system stability and does not inherently require these ongoing functional enhancements. Under the current architecture, migrating to a subsequent major version requires activating the final function level of the current version, which involves mandatory catalog updates. Furthermore, falling back from the new version is restricted exclusively to that same final function level of the prior version. This rigid dependency imposes a severe operational burden and introduces heightened validation risks compared to the migration processes available in version 11 and earlier. For stability-focused users who do not benefit from the new features, this constraint acts as a primary inhibitor to upgrading to newer major versions.

To alleviate this operational overhead and facilitate a more seamless upgrade path across the user base, we request the implementation of the following three mechanisms:


•Policy for Function Levels with Stable Catalog Schemas
Establish a product delivery policy or configuration option where, following the initial function level that introduces catalog schema changes within a major version (e.g., V12R1M501), subsequent function levels maintain a fixed catalog structure, avoiding further schema modifications.


•Exemption from Mandatory Final Function Level Activation for Migration
Allow users to migrate to a subsequent major version from any stable function level at or above FL501, without forcing the activation of the absolute final function level of the prior version. The prerequisites for upgrading should be limited strictly to the application of the latest maintenance code level and the appropriate Fallback SPE (Small Programming Enhancement), thereby decoupling code currency from functional activation.


•Granular Fallback Support from FL100 to the Specific Source Function Level
In the event that an issue necessitates a fallback from the initial function level (FL100) of a new major version, provide a fallback mode that allows a secure rollback directly to the specific, lower function level (FL501 or above) that the user was actively running as their migration source, rather than forcing a rollback to the prior version's absolute final state.

Needed By Quarter
  • Guest
    Jul 16, 2026

    It seems to me that this request is mostly to have Db2 allow users to skip making catalog changes that are introduced during continuous delivery. There is no mechanism to do that. Each function level requires a known catalog level before activation can be allowed. If the prerequisite catalog changes are not there the desired function levels cannot be activated.

    Having said that, in the Db2 12 to Db2 13 migration process we do not change the structure of the Db2 catalog. This means we do not add any new catalog tables, indexes, etc. We do not ALTER any tables. So the first catalog level in Db2 13, V13R1M100, is identical structurally to the last catalog that you had in Db2 12. So if avoiding catalog updates is a requirement then users can stay at function level V13R1M100 or V13R1M500 until the time comes when the user wants to migrate to vnext. At that time all of the required Db2 13 catalog changes would need to be made so that the last Db2 13 function level can be activated.

    Avoiding catalog updates via CATMAINT doesn't mean that the user is not running with new code. The underlying Db2 code base knows that the catalog changes are coming and the code is set to work with and without the catalog updates being made. So even if the desire is to avoid the catalog updates, you're not really avoiding the other code changes that will need those catalog changes.

    While it's technically feasible to satisfy the requirement here, that would require an entirely new Db2 development and service process. This would also mean that each of our customers would be able to have catalogs that look very different from what we expect. We simply would not be able to functionally test every possible combination of catalogs out there. With continuous delivery today, we know what every single catalog will look like. There is no guessing. It's very predictable. And it's easy to test the product.

    For item number 3 (Granular Fallback Support from FL100 to the Specific Source Function Level), users today have the ability to fall back to the previous release and then activate an earlier function level. So I believe we already satisfy this requirement. For example, the user can migrate from Db2 123 to Db2 13.....then fallback to Db2 12 function level V13R1M510.....and then activate an earlier function level (FLs V12R1M100 - V12R1M509).

    I will be attending and speaking at the coming Db2 Technical Seminar in Tokyo is the customer would like to speak more about this topic.

    Reply

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.