This portal is to open public enhancement requests against products and services offered by the IBM Data & AI 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 updateson 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,
Post an idea
Upvote ideas that matter most to you
Get feedback from the IBM team to refine your idea
Specific links you will want to bookmark for future use
Please do not make stabilizing dynamic query again after a REBIND with APPLCOMPAT a normal behaviour
We're DB2z 12 FL508. This is a SAP/R3 application on 2-way data sharing.
We stablized access path of some dynamic SQLs and they worked very well. Note that the packages were at APPLCOMPAT V12R1M500 when we did this.
Lately, the packages were rebound with APPLCOMPAT V12R1M508. We noticed that DB2 stopped using the stabilized access paths thus causing many timeouts on transactions executing those SQLs. We were advised by IBM support that this is a normal behaviour:
"To answer the customer's question about why we don't match when APPLCOMPAT changes, it is normal behavior. We do this because something can change with a different APPLCOMPAT level. The customer should use APPLCOMPAT to ensure there is no behavior change which can cause application problems.
Advancing function level does not affect cache match. It's really about what the package is bound with. If APPLCOMPAT is not specified on the BIND, Db2 for z/OS will pick it up from the zparm. As long as they do not REBIND with a new APPLCOMPAT or change their zparm, then there should be no problem.
So, when a dynamic SQL statement is cached/stabilized, a specific behavior is locked in. Changing APPLCOMPAT can change that behavior, so requires a new cached/stabilized entry."
Why it is considered a normal behaviour for DB2 "not to match" when a rebind to a different applcompat takes place? In my opinion, it makes sense for static but not dynamic SQLs. For us, I see this behaviour a problem. As I mentioned, because DB2 did not use the stablilized access path, we had many timeouts and a severe slowdown of the application then the LPAR.
Is there any plan to introduce a bind parameter or a ZPARM to give us the flexibility to choose whether DB2 should match or not match?
Do not place IBM confidential, company confidential, or personal information into any field.