Some Under-the-Radar Db2 13 for z/OS Features to Consider

Db2 13 for z/OS has been available for some time now, and soon (December 2025) it will be the only version of Db2 supported by IBM. So, we all should be either using Db2 13 already, or well into the process of migrating to Db2 13.

With that in mind, here are a few a lesser-known but compelling new features in Db2 13 for z/OS. That is, these enhancements have not received as much attention as the more news-hogging AI and performance new features. 

Online Removal of Active Log Datasets 

It is now possible to remove active log data sets while Db2 is up and running. This new capability is available in Function Level 500 and above. This can be accomplished using 

–SET LOG REMOVELOG 

Using this new option of the -SET LOG allows you to safely remove an active log data set from the BSDS without requiring downtime—as long as the data set isn't currently in use.

• If the data set is in use, the data set will be placed in a “REMOVAL PENDING” state, making it unavailable moving forward, until explicitly handled.

• If it's the next log to be written, the command fails with “REMOVAL PROHIBITED.”

• You can monitor this using -DISPLAY LOG DETAIL and use D GRS,RES=(*,dsname,*) to check log usage.

This feature greatly reduces operational risk and complexity during log maintenance in active environments.

DDL Lock Management

Db2 13 adds several new controls that help improve availability and reduce contention when performing DDL (data definition) operations:

• CURRENT LOCK TIMEOUT special register: Lets you override the system-level lock timeout (IRLMRWT) on a per-statement basis (values from 1–32767 seconds), limiting how long transactions queue behind DDL.

• DEADLOCK_RESOLUTION_PRIORITY global variable: Assigns a numerical priority (0–255) to help determine which process is likely to win in a deadlock. Higher values make a DDL process less likely to be chosen as a deadlock victim.

• System monitor profiles can now be configured — for both local and remote applications — to automatically set these values and even adjust package release behavior between RELEASE(COMMIT) and RELEASE(DEALLOCATE).

These features provide more granular control over lock management and thereby should help us reduce disruptions, improve the responsiveness of DDL, and help maintain service levels across transactional workloads.

Why These Features Deserve More Spotlight

• Operational impact without fanfare: While AI functions and accelerator improvements grab headlines, these enhancements quietly deliver high-impact capabilities—especially in high-availability, non-stop environments.

• Prevents outages during routine tasks: The ability to remove log datasets live and better manage DDL locking improves reliability and uptime for critical systems.

• Real-world value for DBAs and sysprogs: These are features that seasoned Db2 for z/OS professionals will deeply appreciate—and can use to simplify otherwise risky operations.

---

Bonus: Other Less-Heralded, but Useful Enhancements

From the 2024 continuous delivery updates (without function-level control), these two new capabilities also seem to be flying under the radar:

• Database utilities running on zIIP: APAR PH63832 allows portions of the COPY utility to leverage zIIP processing, reducing CPU costs.

• Targeted statistics deletion: APAR PH63145 lets you delete catalog statistics for a specific partition—without touching the whole object.

Maybe I have missed your favorite under the rader Db2 13 enhancement? If so, please share it with the community in a comment below!

Consider Application-Level Lock Control in Db2 13 for z/OS

It has been close to a year since Db2 13 for z/OS has been generally available. It was announced in April 2022 and delivered for GA on May 31, 2022.

As you think about migrating from Db2 12 to Db2 13, it is inevitable that you will consider the new functionality and capabilities that comes with the new version. I've discussed the AI functionality of SQL Data Insights delivered in Db2 13, but haven't really dug into some of the other interested new features.

Today, I want to briefly discuss application-level lock control. This new feature enables applications to take more control over Db2 locking. If you have applications that could benefit from different lock parameters than the system-wide settings used by Db2, then this new capability could be useful for at least some of your applications and tasks.

The first thing to note is that you must be at Function Level 500 before you can use application-level lock control. Using application-level lock control then requires setting a special register using the SET CURRENT LOCK TIMEOUT statement. This statement can be included in application programs to control the lock wait duration in seconds. The data type is INTEGER with a range of acceptable values from -1 to 32,767. Setting the CURRENT LOCK TIMEOUT to -1 indicates an indefinite wait, setting it to 0 indicates no waiting. 

Most DBAs reading that last sentence will shudder at the possible implications of waiting forever! Fortunately, there is another new DSNZPARM called SPREG_LOCKTIMEOUT_MAX that can limit the upper bound that an application can use for CURRENT LOCK TIMEOUT.

Nevertheless, in order to implement application-level lock control you will need to modify your application code. So, if you want to wait for locks for up to 50 seconds, you would issue

    SET CURRENT LOCK TIMEOUT = 50

Before the SQL that should wait for that duration. 

Of course, any applications using application-level lock control should be monitored for lock contention. This can be done using Db2 monitoring tools, such as Omegamon or Mainview. The trace record IFCID 437 can also be monitored to discover the specific applications and authorization IDs that use this special register.

Deadlock Resolution Control

Similar to controlling the lock timeout duration, Db2 13 also introduced the ability to manage deadlock resolution control at the application level. This is accomplished using a new system built-in global variable. Instead of just relying on the system setting to control deadlock detection, applications can choose to set the new global variable: SYSIBMADM.DEADLOCK_RESOLUTION_PRIORITY 

Valid values range from 0 and 255. The higher the value, the less likely that locks requested by the application will deadlock when the application is involved in a deadlock situation. Applications and users require the WRITE privilege on this global variable in order to be able to issue it successfully.

So, if you want to set this to the max, you would issue

    SET SYSIBMADM.DEADLOCK_RESOLUTION_PRIORITY = 200

And then issue the statement(s) you are concerned about deadlocking. 

Of course, using this global variable does not guarantee that the application won't experience a deadlock because there are other considerations involved that Db2 still must negotiate and consider. 

One final note, you can use Profile tables to set CURRENT LOCK TIMEOUT and SYSIBM.DEADLOCK_RESOLUTION_PRIORITY as this support has been added in Db2 13.

1.