Bypass RLF (Resource Limit Facility) Predictive/Reactive Governor Checks for SELECT Queries Explicitly Routed to IDAA from Db2 z/OS via SET CURRENT QUERY ACCELERATION = ALL

Summary of Current Behavior:
On Db2 for z/OS, the Resource Limit Facility (RLF) governs SQL by enforcing cost based thresholds using ASU time. When a SELECT statement's estimated resource consumption exceeds the defined RLF limit, Db2 either prevents the query from running (predictive governing) or cancels the executing thread with a -905 SQLCODE (reactive governing). These RLF limits are typically calibrated for traditional query execution on the general-purpose processors (CP/zIIP) within the Db2 engine.

Problem Statement:
When a user or application submits a SELECT query with the special register set to SET CURRENT QUERY ACCELERATION = ALL;, the explicit intent is for that query to be offloaded to and executed within the IBM Db2 Analytics Accelerator (IDAA). In this scenario, the RLF governor , at times, can cause faulty calculations that is being applied against queries intended to route to the IDAA appliance for execution, and as a result, can erroneously get cancelled by RLF (e.g., -905 thread termination), even though they would never consume the governed resources on the general processor because the query is intended to run on the IDAA accelerator.

Proposed Enhancement:
Introduce logic whereby, when CURRENT QUERY ACCELERATION is set to ALL, Db2 should bypass or suppress the RLF governor evaluation / calculation for that SELECT statement. Because the query is guaranteed to execute in IDAA under ALL, the z/OS resource limit calculation is not meaningful and should not trigger predictive prevention or reactive thread cancellation.

Scope / Considerations:

• The bypass should apply specifically when acceleration is SET to ALL, where a failure to accelerate results in query failure rather than fallback to native Db2. For ENABLE / ELIGIBLE, RLF governing should still apply in the fallback path to protect z/OS resources.