By Gayatri Biswas, Ganesh Nagarajan, and Tammie Dang 

In IBM Db2 13 for z/OS function level 509, the Resource Limit Facility (RLF) is enhanced to support IP subnet-based filtering in both IPv4 and IPv6 environments, along with local subsystem identification. This enhancement addresses a practical challenge in modern deployments where workload governance rules were previously defined using large numbers of individual IP addresses. As networks become more segmented and dynamically allocated, maintaining address-level rules at scale becomes increasingly difficult.

With this enhancement, RLF can evaluate client activity at the subnet level rather than relying solely on individual IP address matches. A single subnet definition can now represent an entire range of IPv4 or IPv6 addresses, significantly reducing the number of rows required in the RLF DSNRLMTxx table. This simplifies policy definition and reduces ongoing maintenance effort while preserving existing governance semantics.

To illustrate how this works in practice, consider a scenario in which USER1 accesses the application APPX under varying network conditions. The following DSNRLMTxx table content specifies both dynamic and static SQL governance rules using RLFFUNC values ‘8’ and ‘B’, along with subnet-based rules for 192.168.1.0/24 and a more specific 192.168.1.0/26.

When USER1 executes APPX from IP address 192.168.1.100, Db2 applies an ASUTIME limit of 10000 for each dynamic or static query because the exact IP address match has the highest precedence.

When the same user executes APPX from IP address 192.168.1.50, the address qualifies for both 192.168.1.0/24 and 192.168.1.0/26 subnets. Db2 applies an ASUTIME limit of 5000, because 192.168.1.0/26 is the more specific subnet for this IP address.

When USER1 executes APPX from an IP address 192.168.1.200, the address matches only the 192.168.1.0/24 subnet, and Db2 applies an ASUTIME limit of 8000 for each query.

This behavior remains consistent across IPv4 and IPv6 configurations, with subnet precedence determining the outcome when multiple rules apply.

Queries from the local subsystem can also be governed using RLF rules, as shown below.

When any query runs from the local Db2 subsystem, Db2 applies an ASUTIME limit of 9000 for both dynamic and static SQL because the 127.0.0.1 rule explicitly identifies the local application.

The underlying RLF evaluation model remains unchanged. At the start of a unit of work, Db2 captures client attributes such as application name, user ID, workstation name, and IP address. These attributes are used to determine which row in DSNRLMTxx governs the execution of dynamic or static SQL statements. Function level 509 extends this model by introducing subnet-aware matching and local subsystem identification, without altering existing precedence rules.

In environments where multiple rules match, Db2 applies a deterministic evaluation order. Exact IP matches are evaluated first, followed by subnet matches, with the most specific subnet selected when there are overlaps. This ensures consistent behavior across both IPv4 and IPv6 workloads and avoids ambiguity in rule selection.

Overall, IP subnet support in Db2 13 function level 509 makes RLF significantly easier to manage in large and distributed environments. It reduces maintenance overhead for the DSNRLMTxx table, aligns workload governance with modern network architectures, and preserves full compatibility with existing definitions. At the same time, it extends control to subnet-level and local subsystem-based scenarios, improving both flexibility and operational clarity without changing the core governance model.