10 Reasons for the Success of Db2 for z/OS

Db2 for z/OS has proven successful for decades not because of any single feature, but because it consistently delivers on the things that matter most for mission-critical enterprise computing. The biggest reasons fall into a few clear and convincing categories.

1. Unmatched Reliability and Availability

At the top of the list is availability. Db2 for z/OS is engineered to run continuously, often measured in years of uptime rather than days or months.

Key contributors include:

• Robust logging and recovery mechanisms

• Online maintenance (schema changes, reorgs, index builds)

• Data sharing across multiple Db2 members in a Parallel Sysplex

• Automatic restart and failure isolation

For businesses where downtime directly translates to lost revenue, regulatory exposure, or reputational damage, this reliability is non-negotiable... and Db2 has consistently delivered it.

2. Exceptional Performance at Massive Scale

Performance is a hallmark of Db2 systems and applications. Db2 for z/OS excels at high-volume, high-concurrency transaction processing. It routinely handles:

• Tens of thousands of transactions per second

• Millions of SQL statements per hour

• Thousands of concurrent users

This performance advantage is not accidental. Db2 is tightly integrated with IBM Z hardware features such as:

• Specialty processors (zIIP, and previously zAAP which has been rolled into the zIIP funtionality)

• Large memory footprints with sophisticated buffer management

• Hardware-assisted compression and encryption

The result is predictable, repeatable performance even under extreme workloads.

3. Deep Integration with the z/OS Platform

Unlike databases that are merely hosted on an operating system, Db2 for z/OS is co-engineered with z/OS and IBM Z hardware.

This integration enables:

• Advanced workload management (WLM)

• Superior I/O handling

• System-level security and auditing

• Fine-grained resource governance

Because the database, OS, and hardware evolve together, Db2 can exploit platform innovations faster and more effectively than loosely coupled systems.

4. Rock-Solid Data Integrity and Consistency

Db2 for z/OS has earned a reputation as the system of record because it protects data integrity above all else.

This includes:

• Full transactional integrity (ACID compliance)

• Enforced referential integrity and constraints

• Proven locking and concurrency control

• Bulletproof recovery from failures

Enterprises trust Db2 with their most valuable data including financial records, customer accounts, order entry details, healthcare information, flight tracking and more. When correctness is not optional, Db2 for z/OS is the answer!

5. Security Built In, Not Bolted On

Security has always been foundational to Db2 for z/OS, not an afterthought.

Its strengths include:

• Tight integration with RACF and z/OS security services

• Granular authorization at table, column, and row levels

• Native encryption for data at rest and in flight

• Comprehensive auditing and compliance capabilities

For highly regulated industries, Db2 simplifies compliance while reducing risk exposure.

6. Backward Compatibility and Investment Protection

Few platforms can match Db2’s commitment to backward compatibility. Applications written decades ago often continue to run unchanged today.

This provides:

• Long-term investment protection

• Lower modernization risk

• Predictable upgrade paths

Organizations can adopt new Db2 features incrementally without rewriting core applications which is a critical factor in long-term platform success.

7. Continuous Evolution Without Disruption

Db2 for z/OS has evolved continuously while maintaining stability. Over the years it has added:

• Support for new SQL standards

• XML and JSON capabilities

• Temporal tables

• Advanced analytics functions

• RESTful access and modern connectivity

Importantly, these enhancements arrived without forcing disruptive migrations, a balance few platforms achieve.

8. Alignment with Business-Critical Workloads

Db2 for z/OS was designed from the start to support workloads that:

• Cannot fail

• Cannot lose data

• Cannot tolerate unpredictable performance

Industries such as banking, insurance, government, retail, and transportation still depend on these characteristics. As long as these workloads exist, Db2’s value remains clear.

9. A Mature Ecosystem and Skilled Community

Db2 benefits from:

• Decades of operational best practices

• A rich ecosystem of tools (monitoring, tuning, recovery, automation)

• A global community of experienced professionals

This maturity reduces risk and accelerates problem resolution which is another quiet, but powerful, contributor to its success.

10. Trust Earned Over Time

Perhaps the most important reason for Db2 for z/OS’s success is trust. Enterprises have seen it perform reliably through:

• Hardware generations

• Economic cycles

• Technology shifts

• Organizational change

That trust is hard to win... and even harder to replace.

In Summary

Db2 for z/OS has endured not because it resists change, but because it embraces change without compromising stability. Its success rests on a rare combination of reliability, performance, security, and evolution. And these qualities remain just as relevant today as when the platform was first introduced.

Happy Holidays 2025!

There are over two dozen holidays celebrated across the world between November 1st and January 15th? 

It is in that spirit that I want to wish all of my readers -- all over the world and no matter which of those holidays they celebrate -- a very Happy Holiday season!

This will be my last post of 2025, but I will be back posting more about the database management system that we all love -- Db2 -- again in 2026. So, be sure to check back regularly next year for more exciting Db2 content!

 

Happy Holidays, Seasons Greetings, Happy New Year, and All That Jazz!

Don't Forget About Histogram Statistics in Db2 for z/OS

There are a lot of options and parameters to consider when putting together your RUNSTATS jobs to collect statistics on your Db2 data. For those who do not know, RUNSTATS is a Db2 for z/OS utility program that is used to collect information about characteristics of tables and indexes, and storing that data in the Db2 Catalog where it can be used by the Db2 Optimizer to formulate SQL access paths. 

Without reasonable statistics, as collected by RUNSTATS, you will likely experience SQL performance problems because Db2 will be accessing the data based on incorrect or outdated information about your data. As I have discussed before, RUNSTATS is one of The 5 R's of Db2 Performance.

OK, with that introductory bit out of the way, one capability of RUNSTATS, first introduced in Db2 9 for z/OS is somewhat underutilized. As you might guess from the title of this blog post, I am talking about histogram statistics.

But what is a histogram? Well, in mathematical terms, a histogram is a representation of data that shows the distribution of data in a data set. Often represented using a bar graph, each bar represents the frequency of data points within a specific range. However, unlike a typical bar chart (displaying categorical data), a histogram groups numbers into ranges, making it useful for identifying patterns, such as underlying frequency distribution, outliers, and skew.

So, a histogram is a way of summarizing data that’s measured on an interval scale. A histogram is particularly helpful when you want:

• to highlight how data is distributed, 
• to determine if data is symmetrical or skewed, or 
• to indicate whether or not outliers exist.

The histogram is appropriate only for variables whose values are numerical and measured on an interval scale. To be complete, let’s define interval, which is a set of real numbers between two numbers either including or excluding one or both of them.  

Histograms are generally most useful when dealing with large data sets.

Why Use Histogram Statistics?

Db2 historgram statistics can be quite useful for certain types of data. Instead of the frequency statistics, which are collected for only a subset of the data, sometimes Db2 can improve access path selection by estimating predicate selectivity from histogram statistics, which are collected over all values in a table space.

Histogram statistics can help the Db2 Optimizer estimate filtering when certain data ranges are heavily populated and others are sparsely populated. Think about data that represents customers of a diner. Typically, there will be periods of high activity (breakfast, lunch, dinner) and low activity (other periods). Or perhaps on a grander scale, consider data that represents customer activity at a big box store. During big sales (such a Black Friday) and over holidays (Christmas, for example), there will be more sales than during other periods.

Depending on the type and makeup of the data, it can make sense to collect histogram statistics to improve access paths for troublesome queries used with the following predicates: 

• RANGE, 
• LIKE, and 
• BETWEEN. 

Histogram statistics also can help in some cases for equality (=), IS NULL, IN list, and COL op COL predicates.

 

How to Collect Histogram Statistics

 

OK, so how can you go about collecting histogram statistics? Well, the IBM RUNSTATS utility can collect statistics by quantiles. A quantile is the name for a bucket representing a range of data. For instance, from our diner example discussed earlier, you might want to have quantiles representing pre-breakfast, breakfast, pre-lunch, lunch, pre-dinner, dinner, and late night.

Db2 allows up to 100 quantiles. You can specify how many quantiles Db2 is to use: from one up to 100. Of course, specifying one isn’t wise because it’s the same as collecting for everything and so it will not be very helpful.

You do not explicitly define the make-up of quantiles, though. Db2 does that. Db2 creates equal-depth histogram statistics, dividing the whole range of values into quantiles that each contain about the same percentage of the total number of rows. 

You indicate that RUNSTATS should collect histogram statistics by coding the HISTOGRAM keyword in conjunction with the COLGROUP option. This way you can collect histogram statistics for a group of columns. You also must tell Db2 the number of quantiles to collect by specifying the NUMQUANTILES parameter. NUMQUANTILES also can be specified with the INDEX parameter, in which case it indicates that histogram statistics are to be collected for the columns of the index.

 

A single value can never be broken into more than one interval. This means the maximum number of intervals is equal to the number of distinct column values. For example, if you have 40 values, you can have no more than 40 quantiles, each consisting of a single value. In other words, be sure that you don’t specify a value for NUMQUANTILES that is greater than the total number of distinct values for the column (or column group) specified. Also, keep in mind that any NULLs will occupy a single interval.

 

So, then, how do you decide on the number of quantiles to collect? If you don’t specify NUMQUANTILES, the default value of 100 will be used; then based on the number of records in the table, Db2 will adjust the number of quantiles to an optimal number. Therefore, unless you have a good understanding of the application or a viable reason to deviate, a reasonable rule of thumb is to simply let NUMQUANTILES default and let Db2 work it out.

 

RUNSTATS will attempt to produce an equal-depth histogram. This means each interval will have about the same number of rows. Please note that this doesn’t mean the same number of values—it’s the same number of rows. In some cases, a highly frequent single value could potentially occupy an interval all by itself.

 

Where Are the Histogram Statistics Stored?

 

The following columns in a histogram statistics table define the interval: 

• QUANTILENO - a sequence number that identifies the interval
• HIGHVALUE - a value specifying the upper bound for the interval. 
• LOWVALUE - a value specifying the lower bound for the interval

These columns can be found in the following six Db2 Catalog tables: 

• SYSCOLDIST, 
• SYSKEYTGTDIST, 
• SYSCOLDIST_HIST, 
• SYSCOLDISTSTATS, 
• SYSKEYTGTDIST_HIST, and 
• SYSKEYTGTDISTSTATS.

 

Here’s a sample RUNSTATS specification that collects histogram statistics for the key columns of the indexes on tables in the CSMTS02 table space:

 

RUNSTATS TABLESPACE DB.CSMTS02

  INDEX ALL

  HISTOGRAM NUMCOLS 2 NUMQUANTILES 10

  SHRLEVEL(CHANGE)

  UPDATE ALL

  REPORT YES

 

Summary

 

If you have troublesome queries on data that is skewed or disproportionately distributed, you should consider gathering histogram statistics. Keep in mind that running RUNSTATS specifying HISTOGRAM will probably consume more CPU than just gathering frequency distribution statistics, the performance gains from improved access paths for your queries could more than offset that cost.

A Few Details on the TRUNCATE Statement

TRUNCATE is a simple, yet frequently forgotten way to remove data from your Db2 tables.

The TRUNCATE statement is simply a quick way to remove all of the data from a table. The table can be in any type of table space. And the table can be a declared global temporary table. If the table contains LOB or XML columns, the corresponding table spaces and indexes are also truncated.

For clarification, consider the following example:

TRUNCATE TABLE EXAMPLE_TABLE
  REUSE STORAGE
  IGNORE DELETE TRIGGERS
  IMMEDIATE;

But why do we need this statement? Won't a DELETE without a WHERE clause do the same thing? Well, sort of. TRUNCATE will not log any changes, whereas that DELETE would log your changes. That means TRUNCATE should operate more efficiently. But it could be hard to undo.

Seems easy enough, doesn’t it? But what are those additional parameters? 

Well, REUSE STORAGE tells Db2 to empty the storage that is allocated but keeps it allocated. The alternate, which is the default, is DROP STORAGE. This option tells Db2 to release the storage that is allocated for the table and to make it available for use for the same table or any other table in the table space.  

The next parameter, which is the default if nothing is specified, is IGNORE DELETE TRIGGERS. This tells Db2 to not fire any DELETE triggers. Alternately, you could specify RESTRICT WHEN DELETE TRIGGERS, which will return an error if there are any delete triggers defined on the table. In other words, TRUNCATE is not going to fire any DELETE triggers no matter what you tell it, but it can return an error if DELETE triggers exist that you do not know about (for example). 

Finally, we have the IMMEDIATE option. This causes the TRUNCATE to be immediately executed and it cannot be undone. If IMMEDIATE is not specified you can issue a ROLLBACK to undo the TRUNCATE.

Some More Details

So far, so good. But there always seem to be small things that fall through the cracks until you encounter them in the real world. One example is "How does TRUNCATE operate on archive tables?"

There are two considerations to ponder here. First, will the truncated data be moved to the archive like it would with a DELETE statement? The answer is no, TRUNCATE will NOT move the rows it deletes to the archive table. TRUNCATE simply gets rid of the data without archiving it.

The second consideration is if you TRUNCATE a table that has an archive table, will TRUNCATE remove the data in both the base table and the archive table? Again, the answer is no. TRUNCATE will NOT remove rows in the archive table. You have to remove those separately using a TRUNCATE statement directly against the archive table by name to get rid of archived rows.

Another thing I have seen folks get confused about is the STORAGE option. Some assume that specifying DROP STORAGE will cause the operating system allocated storage/files to be removed. That is not the case. The DROP STORAGE option only releases the storage inside the tablespace. This means that you need to run a REORG to fully clean up the space (after you run the TRUNCATE DROP STORAGE). Also, be sure not to specify REUSE when you run the REORG.

Furthermore, specifying DROP STORAGE should remove extents, not allocated space. So if the tablespace is allocated at say 100 tracks you will never go below 100 tracks without either changing the primary allocation or dropping the object. Now if there were say 5 extents of 10 tracks each, truncating and then reorganizing should get rid of those 50 tracks.

What About PBGs?

For Partition-By-Growth (PBG) table spaces, the REORG utility can physically drop data sets associated with partitions that become entirely empty and are at the "end" of the table space. However, this behavior is controlled by the REORG_DROP_PBG_PARTS subsystem parameter (ZPARM) available since Db2 11 for z/OS:

• REORG_DROP_PBG_PARTS = ENABLE: When this is set, reorganizing the entire PBG tablespace will attempt to consolidate all data into the lowest-numbered partition(s). Any trailing partitions (highest-numbered partitions) that become empty as a result of the REORG will have their associated data sets physically removed (dropped).

• REORG_DROP_PBG_PARTS = DISABLE (Default): Empty trailing partitions are retained, and their data sets are not removed.

So keep this in mind if you are attempting to reclaim space in PBG table spaces that have decreased data volume.

A Useful Little Statement

Overall, TRUNCATE is a useful little tool to keep in your quiver. For certain requirements it can be just what the doctor ordered!

The Many Types of Mainframe Pricing

Whenever somebody starts talking about software pricing on the mainframe, or tuning to save on their monthly mainframe bill, I always wonder just exactly "what" they are talking about. Are they aware of all their company’s licensing agreements and all the intricacies they contain?

Before we move on, let me just state that the mainframe still makes good economic sense. The total cost of ownership (TCO) for the mainframe, when you add up all of the cost components (such as hardware, software licenses, storage, network, labor, power and cooling), is similar to or lower than comparable platforms.

So, don’t get me wrong, the mainframe is a great place to run your enterprise applications. And I am all in favor of tuning your code, infrastructure, and environment. But there are many reasons for doing so. Of course, the first reason is to improve the experience of your end users. The more efficiently tuned your software and the system it runs on, the more optimal and pleasant the experience of your end users will be. So, improving your customer experience is always a valid reason for tuning and optimizing your software.

That said, sometimes the intention of tuning efforts gets stated as to reduce costs. And that is a noble goal. But quite frequently, it seems, people undertaking the assignment to tune for cost optimization do not have enough information on achieving that goal!

What must be understood if you are looking to reduce mainframe cost by tuning? Well, I think the first thing you need to understand is what comprises your mainframe cost.

At a high level there is the cost of the IBM Z hardware that has to be taken into account. Of course, there is little that you can do to reduce hardware cost once you have purchased your mainframe. That said, by tuning your workloads to avoid reaching the peak utilization capacity of your mainframe you can avoid the need to upgrade to a new machine (a costly endeavor, indeed). This can be achieved by tuning activity to reduce CPU requirements or by moving workload around to smooth out the peaks. This is something that capacity planners should always be looking at and taking measures to achieve.

The next thing you need to understand is the mainframe software licenses that you have in place. This is not as easy as it might sound. Let’s start with the pricing metrics offered by IBM for Monthly License Charge (MLC) products. The IBM MLC products include operating systems, middleware, compilers, and other system software offerings. Examples of MLC products include: z/OS, z/TPF, CICS, Db2, IMS, COBOL, and so on. These products have a recurring charge that is applied each month for the right to use the product and also access IBM product support. Fair enough, and so far, not overly confusing.

But you also must know the specific MLC pricing metric used by your organization. And there are multiple, including:

           Advanced Workload License Charges (AWLC)

           Country Multiples License Charges (CMLC)

           Variable Workload License Charges (VWLC)

           Flat Workload License Charges (FWLC)

           Advanced Entry Workload License Charges (AEWLC)

            Entry Workload License Charges (EWLC)

            Tiered Workload License Charges (TWLC)

            System z New Application License Charges (zNALC)

            Parallel Sysplex License Charges (PSLC)

            Midrange Workload License Charges (MWLC)

            zSeries Entry License Charges (zELC)

            Growth Opportunity License Charges (GOLC)

Each of these metrics has specific requirements and specific conditions for how MSU usage is charged. Some of these metrics, such as AWLC and VWLC, offer sub-capacity licensing. That means that the software charges are based on the utilization capacity of the logical partitions (LPARs) on which the product runs. There are many nuances to how this actually works, but the bottom line is that if you can tune workloads that run during a peak rolling four-hour average (R4HA) period for the month, you can likely reduce your monthly bill.

Of course, there are also full-capacity metrics, where all software charges are determined by the full IBM-rated capacity (MSUs) of the CPC in which a product runs. Examples of full capacity based pricing metrics are PSLC and zELC. 

With the sub-capacity pricing metrics above your monthly bill can vary, sometimes substantially, from month-to-month. IBM introduced Tailored-Fit Pricing (TFP) for organizations looking for a predictable monthly bill. The general approach of TFP is to provide a predictable cloud-like pricing option for IBM z software. At a high-level, your overall usage for the last year is reviewed and an estimated increase is factored into the usage. Your monthly bill for the upcoming year is then 1/12 of last year’s total usage (plus the increase).

Then we have to consider International Program License Agreement (IPLA) products, which have an up-front license fee and an optional annual maintenance charge. IPLA products include tools for managing Db2, CICS, IMS, and others. To further complicate matters, at least when trying to tune for cost reduction, some mainframe IPLA products can be licensed at a sub-capacity level. 

And let’s not forget Container Pricing for IBM Z, where certain defined workloads can scale without impacting other workloads, either within an existing LPAR, separate LPARs, or multiple LPARs.

The Bottom Line

Given this general information, you can see how the choice of pricing metric will impact the efficacy of your tuning to reduce costs. Before undertaking any mainframe cost optimization effort be sure that you understand the different licenses for IBM Z software that are in effect at your organization. Furthermore, it is essential that you have effective tools for monitoring your CPU utilization, including identify monthly peaks. Armed with sufficient information and proper tools (including tuning and modernization tools), your chances of achieving cost reduction will increase greatly!

--- 

For additional information on mainframe pricing metrics and how zIIPs can help, check out my book on the topic: IBM Mainframe Specialty Processors: Understanding zIIPs, Licensing, and Cost Savings on the IBM Sytem z.

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!

Mainframe Relevance in an AI-First Era: How Db2 Fits

For decades, the IBM Z mainframe has been the backbone of mission-critical computing. Db2 for z/OS sits at the center of this story, reliably managing the world’s most sensitive and high-value data. Yet in today’s IT landscape, dominated by discussions of artificial intelligence (AI), machine learning, and data-driven transformation, the question inevitably arises: 

Where does Db2 fit in an AI-first world?

The answer is clear: Db2 remains central. In fact, it is uniquely positioned to power and support enterprise AI initiatives.

The Foundation of Trustworthy Data

AI is only as good as the data that feeds it. Models trained on incomplete, inconsistent, or inaccurate data produce unreliable outcomes. This is where Db2 shines. With its proven capabilities for data integrity, security, and availability, Db2 for z/OS provides the foundation of trustworthy, enterprise-grade data that AI depends upon.

Organizations already store their most critical operational data in Db2. Leveraging this data directly—without needing complex ETL processes that move it into less secure environments—offers a significant advantage. AI workloads can run against reliable, current data with governance and compliance controls already in place.

Db2 and Embedded AI Capabilities

IBM has not stood still in bringing AI to Db2 for z/OS. For example, Db2 AI for z/OS (Db2ZAI) uses machine learning models to improve database performance. By analyzing workload patterns, Db2ZAI can recommend optimal buffer pool configurations, predict query performance, and even assist the optimizer in choosing the best access paths. This closes the loop: AI is being applied inside Db2 itself to make database management more intelligent and efficient.

Similarly, SQL Data Insights brings AI-powered analytics directly into Db2 for z/OS, enabling built--in SQL functions to use AI for anomaly detection and data pattern recognition without requiring external AI platforms. These capabilities allow organizations to unlock the hidden value in their Db2 data more quickly and intuitively.

Synergy with IBM Z and AI Acceleration

The hardware platform itself reinforces this story. The latest IBM z16 and z17 mainframes incorporate on-chip AI acceleration with the Telum processor and Spyre AI accelerator. This means that inferencing can be performed where the data resides, avoiding latency and risk associated with data movement. For financial institutions detecting fraud, retailers optimizing transactions, or insurers assessing claims, the ability to apply AI in real-time on operational data is transformative.

Db2, running on these systems, is directly positioned to take advantage of this capability—turning the mainframe into not just a system of record, but also a system of insight and decision.

The DBA’s Evolving Role in an AI-First Era

As AI integrates more deeply into Db2, the role of the DBA also evolves. No longer solely the guardian of performance tuning and availability, the modern DBA must understand how AI tools are being embedded in their environment. This includes evaluating AI-driven recommendations, integrating AI queries into business applications, and ensuring that AI workloads are governed and secure.

Rather than diminishing the DBA’s importance, AI amplifies it. Human expertise is needed to validate, interpret, and operationalize AI-driven insights in ways that align with business priorities and regulatory requirements.

Conclusion

The narrative that positions mainframes and Db2 as “legacy” is misguided. In reality, Db2 for z/OS sits at the heart of enterprise AI adoption. With its unmatched reliability, native AI capabilities, and synergy with IBM Z’s AI-accelerated hardware, Db2 is not only relevant but critical in an AI-first world.

For organizations pursuing AI, the best path forward often starts with the data they already trust most—residing in Db2. The mainframe is not being left behind by AI; it is, in fact, helping to lead the way.

Machine Learning and AI Integration in Db2 for z/OS

In today’s data-driven world, the ability to harness the power of machine learning (ML) and artificial intelligence (AI) is essential for organizations aiming to stay competitive. With the introduction of Db2 for z/OS Version 13 and subsequent function levels, IBM has made significant strides in integrating ML and AI capabilities directly into the Db2 ecosystem, transforming the way businesses leverage their data.

SQL Data Insights

Perhaps the single most important new AI capability added to Db2 13 for z/OS is SQL Data Insights (SDI). I have written about this before and if you are interested in a more thorough discussion of SDI, check out this article on elnion.

At a high level though, SDI enables data scientists and analysts to run advanced analytics directly on data residing in Db2 without the need for extensive data movement. By minimizing data transfer, organizations can reduce latency and improve the efficiency of their workflows.

The initial support for SDI in Db2 13 for z/OS FL600 included three AI functions: AI_SIMILARITY, AI_SEMANTIC_CLUSTER and AI_ANALOGY. Function level 504 added a fourth: AI_COMMONALITY.

Python Support

Python is the dominant programming language for AI and ML because of its simplicity, readability, and vast ecosystem of libraries. It offers clear syntax allowing data scientists and developers to focus on solving problems rather than wrestling with complex code structures. This makes it ideal for rapid prototyping of AI models. Rich frameworks such as TensorFlow, PyTorch, and others provide ready-to-use tools for data preparation, model training, and evaluation, significantly reducing development time. Moreover, Python’s large, active community continually contributes new algorithms, techniques, and integrations, ensuring that it stays at the forefront of AI and ML innovation. This combination of usability, flexibility, and ecosystem maturity has made Python the de facto standard for building, deploying, and operationalizing AI and ML solutions across industries.

With Python being so important to data scientists, it stands to reason that IBM should support it in Db2 for z/OS. And they do! Python support for Db2 for z/OS was delivered with the IBM Db2 AI for z/OS and the Db2 for z/OS Python driver as part of the IBM Db2 for z/OS “Data Server Driver for ODBC, CLI, and .NET” family.

• IBM Db2 AI for z/OS (Db2ZAI) is an advanced solution designed to enhance the operational performance, reliability, and efficiency of Db2 for z/OS systems. By leveraging machine learning (ML) and artificial intelligence (AI), it improves many aspects of Db2 management. We will discuss it in a little more detail in the next section.
• The Python driver is IBM's official database connectivity driver that allows Python applications to connect to and interact with IBM DB2 databases. It delivers connectivity not just for Db2 for z/OS, but also for other IBM database products including DB2 for Linux/Unix/Windows, DB2 for i (AS/400), and IBM Informix.

So, Python support became generally available via IBM Db2 for z/OS Distributed Data Facility (DDF) using the IBM Data Server Driver for Python, which is the same Python driver used for Db2 LUW, but configured to connect over DRDA to Db2 for z/OS.

This wasn’t tied to a specific Db2 function level—rather, it was an enhancement to the client connectivity stack and supported back to Db2 11 for z/OS with the right PTFs. Of course, as of this December (2025) Version 13 will be the only supported version of Db2 for z/OS.

Machine Learning Enhanced Optimization

The Db2 optimizer can also benefit from an infusion of AI. Optimization improvement is a benefit of IBM’s Db2 AI for z/OS, an add-on solution that uses AI/ML to elevate system operations and performance.

IBM Db2 AI for z/OS continuously analyzes workload patterns, system metrics, and SQL execution behavior to recommend or automatically apply optimizations—such as selecting better access paths, tuning buffer pools, or adjusting configuration settings to reduce CPU usage. By learning from an organization’s actual Db2 workload over time, it adapts its recommendations to evolving data and usage patterns, helping maintain consistent performance without constant manual tuning.

In addition, Db2 AI for z/OS can assist in workload management, anomaly detection, and operational decision-making, giving DBAs intelligent, data-driven insights to run large-scale mainframe database systems more efficiently. By incorporating machine learning into key processes it can help to reduce CPU usage, optimize SQL query plans and concurrency, and detect and resolve anomalies and root causes.

Indeed, the AI-driven operational support of Db2 AI for z/OS goes beyond using AI in SQL queries. It is focused on keeping Db2 for z/OS environments running optimally and proactively, enhancing system resiliency and availability.

Summing Things Up

IBM continues to integrate machine learning and AI capabilities into Db2 for z/OS. By empowering organizations to leverage their data for predictive analytics and advanced machine learning, IBM is helping businesses unlock new opportunities and drive smarter decision-making. As these technologies continue to advance, the potential for innovation and growth in the data landscape is limitless. Embrace the future of data with Db2 for z/OS and unleash the power of AI and machine learning in your organization today!

Consider DBHawk as a Data Studio Replacement

Although IBM Data Studio is still available, its support and feature focus for Db2 have shifted significantly. Things are a little different for z/OS and LUW environments though. So, let’s take a look at the current situation with IBM Data Studio and then look at Datasparc’s DBHawk as a possible replacement.

The Data Studio Situation

For Db2 for z/OS, IBM is phasing out Data Studio for mainframe use. Perhaps “phasing” is too soft of a term – “has already phased” is more appropriate. Data Studio support for Db2 z/OS ended March 31, 2025. This means that IBM is no longer providing standard support for Data Studio for Db2 for z/OS. Furthermore, Data Studio does not officially support Db2 for z/OS Version 13 and later. Db2 13 is the current version of Db2 for z/OS and support for DB2 12 for z/OS itself ends on December 31, 2025. So, time is running out if you still rely on Data Studio for mainframe Db2.

IBM touts two different potential replacements for Data Studio from within its product portfolio:

• Db2 Administration Foundation – a browser‑based tool for Db2 z/OS DBAs.
• Db2 Developer Extension – a free Visual Studio Code extension tailored for SQL application development.

Replacing one tool with two has caused some confusion and dissatisfaction within the Db2 for z/OS community. Regarding Db2 Administration Foundation, it is not easy to install. Data Studio users are accustomed to just downloading the software to their PC and using it. Installing Admin Foundation requires additional systems software (Zowe and IBM Unified Management Server) necessitating the involvement of systems programmers. As such, many sites have delayed moving forward with Admin Foundation.

The Db2 Developer Extension is easier, but it requires you to use Microsoft Visual Studio Code. Not every organization does so.

For Db2 LUW (Linux, UNIX, Windows), IBM Data Studio continues to work. The product page confirms it remains the integrated environment for database development and administration across LUW IBM. However, the latest stable release is Data Studio 4.1.x, with version 4.1.4 released in late 2021. Four years is an eternity between software releases and given the current state of Db2 for z/OS support for Data Studio it may be wise even for Db2 LUW users to look for longer-term alternatives.

DBHawk: An Interesting Alternative

Datasparc DBHawk is a comprehensive, web-based platform designed for secure database management, application development, and data analytics across a wide range of databases, including IBM Db2 (both LUW and z/OS). Its unified IDE and security-centric features make it especially valuable for organizations seeking to streamline workflows, enhance collaboration, and maintain robust data governance.

DBHawk can be used to develop and manage Db2 databases and applications in several impactful ways:

• Web-Based SQL Development: DBHawk offers an advanced SQL editor with a user-friendly web interface that supports building, modifying, and executing SQL queries for Db2, eliminating the need for desktop installation and enabling access from anywhere.
  
  
• Cross-Database Compatibility: While IBM Data Studio focuses primarily on Db2, DBHawk supports multiple databases including Db2, Oracle, SQL Server, PostgreSQL, MySQL, AWS RDS, and many more. This makes it ideal if your environment includes heterogeneous databases or if you plan to expand beyond Db2.
  
  
• Text-to-SQL (AI Integration): The new text-to-SQL feature allows users to interact with Db2 using natural language, lowering the barrier for non-SQL experts to query data. This is an optional feature and administrators can control this feature to turn on or off.
  
  
• Centralized Security and Auditing: DBHawk provides robust centralized security features, including data access policies and auditing capabilities, helping organizations meet compliance requirements such as GDPR and HIPAA. 
  
  
• Self-Service Reporting and Dashboards: Beyond database development, DBHawk includes business intelligence tools like dynamic SQL charts and dashboards, enabling developers and analysts to create reports directly within the platform. IBM Data Studio lacks integrated BI/reporting features.
  
  
• Collaboration and Sharing: Teams can share SQL queries, reports, dashboards, and code snippets securely, supporting collaborative development and analytics.
  
  
• Automation and Batch Job Management: DBHawk supports automating SQL tasks and batch jobs through its web platform, streamlining routine database administration and development workflows, which can improve productivity compared to IBM Data Studio’s manual processes.
  
  
• No Client Installation: Being a browser-based tool, DBHawk requires no client installation, simplifying deployment and updates across teams.

DBHawk supports flexible deployment options, including Docker, Kubernetes, and cloud services, and integrates with enterprise authentication systems (SAML, LDAP, SSO). It is suitable for both on-premises Db2 installations and cloud-hosted instances (e.g., Amazon RDS for Db2).

Of course, DBHawk does not 100% replace all the functionality of Data Studio. If you rely on Data Studio for IDAA administration or require visual Explain functionality, DBHawk probably will not be helpful for those tasks.

Nevertheless, DBHawk can serve as a versatile, centralized, and web-accessible alternative to IBM Data Studio for Db2 development and management, especially if your needs extend to multi-database environments, enhanced security compliance, and integrated reporting capabilities.

Summary

DBHawk provides a modern, secure, and highly collaborative environment for Db2 application development and database management, combining advanced development tools, automation, and enterprise-grade security in a single web-based platform. This makes it an effective solution for organizations seeking to improve productivity, enhance data security, and simplify compliance in their Db2 environments.

IDUG Db2 Tech Conference 2025 Highlights

I had the good fortune to attend the North American IDUG Db2 Tech Conference in Atlanta, Georgia the week of June 8 through June 12, 2025, and as usual, the conference was phenomenal. If you are a Db2 developer, DBA, consultant, or user of any type there was a ton of content being shared. And there were many opportunities to mingle with peers to discuss and share your Db2 tips, tricks, and experiences. And that is probably the most beneficial part of the whole IDUG experience.

I’ve been going to IDUG conferences for a long time now. I’ve been to them all except the very first one. And yes, IDUG has changed a lot over the years, but it is still the preeminent user experience for Db2 professionals… that is, it is not to be missed!

So there I was on Monday morning, one of the many attendees filing into the opening session expectantly...

I took a seat among the crowd... and the first key takeaway from the event for me is that there are more new attendees going to IDUG than ever before. It was stated at the opening session that about 10 percent of attendees were first-timers. That is great news because the more new people exposed to IDUG the better! Even better, it was announced that there are over 16,000 IDUG members now.

The first keynote session, on Monday, was sponsored by IBM and it was titled Leveraging your Db2 Data for Enterprise AI. The keynote featured Minaz Merali, Vice President, IBM Z Data & AI and Priya Srinivasan, Vice President, IBM Core Software Products, Software Support & SRE. And yes, this session was heavy into IBM’s AI strategy, which is appropriate as AI is the driving force of IT these days. Indeed, it was said that IBM is branding itself as the hybrid cloud and AI company!

Another interesting tidbit from the keynote is that "Today only 1% of enterprise data is currently being leveraged by GenAI." So, we've still go a long way to go! Also, 90% of enterprise data is unstructured, which requires a completely different way of processing and analyzing than traditional, structured data. 

The speakers also identified four primary ways to scale AI with Db2 across the enterprise: application building, human productivity, performance, and integration. 

And it sure felt good to hear IBMers promoting Db2 loudly for all to hear. It sometimes feels like Db2 is a forgotten jewel that IBM doesn't promote as much as they should. But it does not feel that way at IDUG. The keynote speakers hammered home the point that IBM Db2 powers the modern economy! 

The top ten largest banks, insurance, and auto companies all rely on Db2! And 70 percent of the world's transactions run on the IBM Z mainframe.

But perhaps my favorite comment of the IBM keynote session was made by a user, Chris Muncan (Sr. Mainframe Db2 DBA at Sun Life), who was participating as part of a user panel. He called “legacy” systems “legendary” instead! I think I'm going to use that.

As an aside, I started feeling old as I listened to people talking about 15 or 20 years of experience and realizing that is still post-2000! I sometimes still think of 20 years ago as being in the 1980s!

I also delivered two presentations myself at IDUG. The first one was Monday, right after lunch, titled "Index Modernization in Db2 for z/OS." The general thrust of the presentation is that technology is evolving, and Db2 has changed a lot. As such, the same indexing strategies that worked well 10 or 20 or more years ago are no longer optimal. The presentation started with a brief review of the critical role of indexes and their history in Db2 for z/OS. Then I covered the many innovations IBM has applied to indexes in Db2 for z/OS over the past few releases including things like index compression, Fast Traverse Blocks (FTBs), and index features like include columns and indexing on expressions. Here I am talking about one of the newer index features, FTBs:

I also reviewed some of the many other changes that could impact indexing strategy including changing data patterns, analytics and IDAA, data growth, and the surge in dynamic SQL. Then I took at look at ways to examine your current index deployment and looking for ways to modernize and improve indexing at your shop.

Well, the topic must have struck a chord with attendees because I was ranked as the best user speaker at the conference! 

Thank you to all of the attendees who ranked my topic so highly, I am truly appreciative!

Later in the day the vendor expo hall opened and all the attendees were able to talk to the vendors about their products. I always take advantage of this great opportunity to chat up the knowledgeable folks at the vendor booths. Indeed, last year I was able to talk to the Rocket Software team to add a crucial feature to the Db2 Admin Tool for a client of mine!

This year, I also spent some time with the InfoTel team at their booth to help them promote their DB/IQ solutions for Db2 for z/OS. 

And two lucky winners walked away with a copy of my book, A Guide to Db2 Performance for Application Developers.

Day two opened with a keynote session from Greg Lotko of Broadcom - a fun session tying local "treasures" of Atlanta to Broadcom's Db2 solutions. 

Tuesday was also the day I delivered my second presentation, an updated version of My Db2 Top Ten Lists, which I first presented over 20 years ago at IDUG. Of course, this version was almost entirely new, but also contained some gems from past iterations of the lists. The lists run the spectrum of Db2 topic areas and provides me the opportunity to discuss a wide array of different Db2-related “things.” 

Of course, there were many more great sessions at IDUG from the likes of Tony Andrews, Thomas Bauman, Roy Boxwell, Brian Laube, Chris Muncan, and many more. I cannot list every great speaker from the event or this post would run on forever, and it is already quite long. But the complete grid of presentations and speakeds can be viewed on the IDUG website here. A few other things that I want to mention are:

• The great Women in Technology keynote session from day three "Harnessing the Power of Adaptability, Innovation, and Resilience" delivered by Jennifer Pharr Davis. 
• The Db2 for z/OS Spotlight session where Haakon Roberts illuminated everybody on highlights of how to prepare for the future of Db2 for z/OS.
• And the Db2 for z/OS Experts Panel - which is always a highlight of the event for me - where a body of IBM and industry luminaries take questions about Db2 for z/OS from the attendees.

Finally, there were nightly events hosted by the vendoes but the only one I attended this year was the IBM outing held at the Georgia Aquarium. The aquarium is one of the largest in the world and it contains some very large aquatic beasties including whale sharks, beluga whales, manta rays, and more. Here are some photos:

All in all it was a great week... if you are an IT professional who works with Db2 in any fashion, be sure to plan your trip to the next IDUG event in your area!