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 for this presenation. 

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! 

 

Common Misconceptions About zIIPs

Most mainframers know that IBM zIIP processors are a type of specialty processor that augments the general-purpose IBM Z CPUs. Instead of running all workloads on the general-purpose CPUs, specific workloads are shuttled to the specialty processors for execution.

The zIIP, or Integrated Information Processor, was initially created for processing certain, specific types of Db2 for z/OS workloads, but over time the work that can be processed on the zIIP has expanded. Nevertheless, the primary reason for using a zIIP is to reduce costs. This is the case because IBM will not impose monthly software charges on workloads that run on the zIIP.

When you install and start using zIIPs, some percentage of the relevant workload can be redirected off of the general processors onto the zIIP specialty processor. But take note, not everything can run on the zIIP. Only workloads that IBM deems as zIIP-eligible are permitted to run on the zIIP.

Generally speaking, this is newer workloads, that is, things that will encourage more work to run on the mainframe. That is why you won’t see CICS transactions or batch workload as zIIP-eligible, other than for specific components of the work that match up with zIIP-eligible features as defined by IBM.

Common Misconceptions

And that brings us to the main topic of today’s post. There are several common misconceptions about IBM zIIP processors. Let’s examine some of them and dispel the misconceptions.

zIIP Processors are Only Useful for Db2

One of the most common misconceptions about zIIP processors is that they are only useful for offloading Db2 workloads. In reality, zIIP processors can offload a wide range of workloads, including Java processing, XML parsing, and encryption/decryption. Another interesting capability of IBM Z mainframes that is zIIP-eligible is the System Recovery Boost. This enables you to take advantage of all of your processing power when starting or restarting your system. This type of boost enables quicker restart and diminishes downtime.

zIIP Processors are Expensive

Another misconception is that zIIP processors are expensive to purchase and operate. While zIIP processors do require a separate license, they are generally less expensive than general-purpose processors, and their use can result in cost savings by offloading workloads from more expensive processors.

The cost of a zIIP license can vary depending on the specific terms of the license agreement and the number of zIIP processors being used. IBM typically charges a one-time fee for each zIIP processor license, as well as an annual maintenance fee. The cost of the license and maintenance fees can vary depending on the specific terms of the agreement, the number of zIIP processors being used, and other factors.

As another consideration, it is quite conceivable that using zIIPs can help you to forestall costly system upgrades. If workload can be processed on cheaper zIIPs, your general purpose processors can be utilized for additional workload that might not have been possible to support if the workload running on the zIIPs had to still run on the general purpose processors. And that means you might be able to run your existing hardware longer and thereby put off the cost of an upgrade.

zIIP Processors are Less Powerful than General-Purpose Processors

Some people believe that zIIP processors are less powerful than general-purpose processors. There is nothing special about a zIIP processor that makes it different than a general purpose processor. It is the same hardware. The difference is that only specific workloads are supported. So zIIPs are just as powerful as general-purpose processors when it comes to offloading those workloads.

That said, it is possible that your zIIPs are actually more powerful than your general purpose processors. Depending on the type and model mainframe system you are running, your general purpose CPU may be knee-capped, meaning that it does not run at the full speed it capable of running. However, zIIPs are never knee-capped, so for a knee-capped system the zIIP processor will be more powerful than the general purpose processor.

zIIP Processors are Difficult to Manage

Another misconception is that zIIP processors are difficult to manage. In reality, zIIP processors can be managed using the same tools and processes as general-purpose processors, and IBM provides tools to help administrators monitor and optimize zIIP usage.

zIIP Processors are Only for Large Organizations

Some people believe that zIIP processors are only useful for large organizations with complex workloads. However, zIIP processors can be useful for organizations of all sizes, and can help reduce costs and improve performance for a wide range of workloads.

zIIPs Cannot Help with COBOL Workloads

Generally speaking, a typical COBOL program will not likely be able to benefit from zIIPs. But, yes, zIIP processors can be used to offload some portion of your COBOL workloads. And not just COBOL, but any workload that meets the zIIP-eligibility criteria can be run on zIIP processors.

Some portion of your COBOL workloads can be offloaded to zIIP processors if it meets the zIIP-eligibility criteria. For example, if a COBOL application is accessing a Db2 database, some portion of the workload that is related to database access can be offloaded to zIIP processors. One such example is SQL that is run as a parallel query can be offloaded to the zIIP.

Assuming Everything Will Run on the zIIP

Another misconception is the assumption that everything that is eligible to run on the zIIP will actually run on the zIIP. Although this may seem like a reasonable assumption, not everything that is zIIP-eligible will actually run on the zIIP.

Some percentage of the relevant workload will be redirected off the main CP onto the zIIP – but not 100% of the workload. When an enclave is created by a product you are using, a parameter can be set to impact the CPU percentage that z/OS can make eligible to run on the zIIP.

Take a look at the Db2 13 for z/OS documentation page titled Authorized zIIP uses for Db2 processing, you will see that not all zIIP-eligible workloads are 100% eligible. For example, the DRDA workloads using TCP/IP and native REST calls over HTTP are up to 60% offloadable to the zIIP.

Furthermore, if the zIIPs are stressed it is possible, based on your configuration choices, that zIIP-eligible workload can run on the main CPs. So, not everything that is zIIP-eligible will actually run on your zIIPs. But enough likely will to make them cost-effective.

Synopsis

Overall, zIIP processors are a powerful and cost-effective tool for offloading specific workloads on IBM Z mainframes. While there are some common misconceptions about zIIP processors, understanding their capabilities and limitations can help organizations make informed decisions about their use.

 

Good Resources for Db2 for z/OS Information

Just a short blog post today to provide a nice chart of useful Db2 for z/OS sites on the web for you to bookmark and use!

Site	Type	Strengths
IBM Db2 for z/OS Page	Official Information	Latest features, product positioning, modernization guidance
IBM Redbooks	Supplementary / Use Cases	In-depth scenarios, practical implementation advice and details
Db2 for z/OS Doc	Documentation / Manuals	Comprehensive details, for each version, regularly updated
IDUG	Community site	User experiences, best practices, conference information
Craig Mullins website	Consultant site	Articles, Links, and Presentations

The Role of Db2 DBAs in Promoting zIIP Usage

 As most z/OS practitioners know, zIIP processors can provide significant benefits in terms of cost savings and improved performance. And one of the most significant areas for taking advantage of the benefits that zIIPs can provide is within Db2 for z/OS. As such, the role of Db2 DBAs in promoting zIIP usage can be critical.

It is important to note that not all features of Db2 for z/OS can run on zIIP processors, and that the extent to which a particular workload can be offloaded to zIIP processors depends on several factors, including the workload characteristics, system configuration, and the Db2 for z/OS version and licensing.

Of course, the first thing you need to be sure of is that the system is configured to utilize zIIPs. This means you must procure a license from IBM to use zIIPs. But you also need to ensure that you have configured your system appropriately for zIIPs, which is usually done by the system programming team. Configuration issues include:

• Ensuring that sufficient zIIP weight is defined for LPARs where Db2 for z/OS workloads run, and
  
  
• Using simultaneous multi-threading in the z/OS LPAR on z13 or later processors to increase zIIP capacity (when only one zIIP engine can be dedicated to the LPAR)

Once the system is properly configured, Db2 DBAs need to immerse themselves in understanding what type of workloads are zIIP-eligible. IBM documents the authorized zIIP uses for Db2 processing for each version of Db2 for z/OS. DBAs should bookmark this page (for Db2 13 for z/OS) and return to it for clarification as needed.

As a high-level guide, the following Db2 processing can run on zIIPs:

• Up to 100% of Db2 system agents processing running under enclave SRBs that execute in the MSTR, DBM1, and DDF address spaces are zIIP-eligible (except for P-lock negotiation). This includes things like buffer pool processing, log reading and writing, index pseudo-deletes and so on. In other words, things that Db2 will be doing as part of its general operation. These are not generally things that DBAs can influence or encourage much one way or the other, but can deliver benefits by offloading work from the general purpose CP to zIIPs.
  
  
• Up to 60% of distributed SQL that uses DRDA to access Db2 over TCP/IP and native REST calls over HTTP are zIIP-eligible. This can be a significant source for offloading work to zIIPs. DBAs can work with development teams to encourage the use of distributed SQL to further their organization’s usage of zIIPs.
  
  
• Up to 100% of parallel query child processes can be run on zIIPs, after you have reached a preset CPU threshold (which is defined by IBM for each specific model of IBM Z). DBAs can help to encourage parallelism, where appropriate, to further zIIP usage. This can be done by binding packages using DEGREE(ANY) or by setting CURRENT DEGREE to ANY. Furthermore, since parallelism can only be used by read-only queries, encourage developers to identify appropriate cursors as FOR READ ONLY.
  
  
• Up to 100% of XML processing for XML schema validation and non-validation parsing, as well as for the deletion of unneeded versions of XML documents. So, if you are using XML in your Db2 databases and applications, certain processing-intensive XML operations can be run on zIIPs.
  
  
• Many IBM Db2 utility processes are also zIIP-eligible. Up to 100% of the index maintenance tasks for LOAD, REORG, and REBUILD INDEX are zIIP-eligible. And up to 100% of the statistics-gathering portion of RUNSTATS is also zIIP-eligible. Planning and executing IBM Db2 utilities is something else that DBAs can do to encourage zIIPs usage. For example, encourage developers to use the LOAD utility instead of writing programs to load or bulk insert a lot of data whenever possible.
  
  
• And up to 100% of the SQL AI functions (SQL Data Insights) in Db2 13 for z/OS that is eligible to be run as a parallel query child process are zIIP-eligible. It is a bit more complex than that, because a portion of SQL statements that reference AI functions but are ineligible to be run as a parallel query child process may still be eligible if the SQL request is made through DRDA. Therefore, utilizing, where appropriate, the SQL Data Insights AI functions (AI_ANALOGY, AI_COMMONALITY, AI_SEMANTIC_CLUSTER, and AI_SIMILARITY) can help bolster the usage of zIIP processors.

I would be remiss if I did not mention that other ISVs offer Db2 utilities with varying degrees of zIIP eligibility; for example, BMC Software, Broadcom, and InfoTel. So, if you have Db2 utilities from vendors other than IBM, be sure to consult their documentation for details on their zIIP exploitation and proceed accordingly.

Furthermore, components of other types of system software may be zIIP-eligible, so be sure to investigate and document which products that you regularly use may be able to utilize zIIPs. For example, if you have heavy sorting requirements Precisely’s Syncsort MFSort can offload a good percentage of sort workload to zIIPs.

And do not forget about Java! Applications written in Java can be redirected to run on zIIPs. So, instead of writing a new application in COBOL (or another language that is not zIIP-eligible) consider using Java to create more zIIP eligible workloads. You might even take a look at where and when it makes sense to convert some existing workloads to run on a JVM to expand you zIIP usage.

On-going DBA zIIP Responsibilities

The DBA’s involvement with zIIPs does not end after workload has been made eligible. On-going activity is required to ensure effective zIIP usage. Db2 DBA must: 

• Monitor performance: Db2 DBAs should monitor system performance to ensure that zIIP processors are being used effectively. This involves tracking zIIP processor utilization, general-purpose CPU utilization, and overall system performance.
  
  
• Optimize performance: Furthermore, Db2 DBAs can help optimize performance by making changes to the system configuration or adjusting workload placement to improve zIIP processor utilization and overall system performance.

And finally, Db2 DBAs should take it upon themselves to educate other team members about zIIPs, their benefits, and how Db2 workloads can take advantage of zIIPs to reduce cost.

The Bottom Line

In summary, the role of a Db2 DBA in promoting zIIP usage involves identifying eligible workloads, ensuring the system is configured appropriately, monitoring performance, optimizing performance, and educating other team members on the benefits of zIIP processors. It can also include encouraging zIIP usage by educating and training developers on what types of processes are zIIP eligible. By promoting zIIP usage, a Db2 DBA can help improve system performance, reduce costs, and improve overall efficiency on IBM Z mainframes.

 

Db2 13 for z/OS Brings Precision with Statement-Level Invalidation

In the ongoing evolution of Db2 for z/OS, each new release brings capabilities that aim to improve efficiency, reduce overhead, and increase system availability. Db2 13 for z/OS continues this trend with a subtle but powerful enhancement: statement-level invalidation. It’s a change that may not grab headlines, but for DBAs and performance tuners, it’s a game-changer.

The Problem with Broad-Stroke Invalidation

Traditionally, when an object such as a table or index was altered, Db2 would invalidate entire packages. This broad-brush approach meant that even if only a single SQL statement within a package was impacted by the change, the entire package would be invalidated and require a rebind. In systems with large, complex applications and tightly integrated SQL packages, this could lead to unnecessary overhead, longer recovery windows, and potential disruptions during rebind processing.

This was particularly problematic in high-availability environments or continuous delivery models, where minimizing disruption is paramount.

Enter Statement-Level Invalidation

Db2 13 introduces a more precise approach. Rather than invalidating an entire package, Db2 can now invalidate only the specific SQL statements within the package that are impacted by a DDL change. The rest of the package remains intact and executable.

This capability is part of a broader initiative within Db2 to support more granular control and management of SQL execution, ultimately enabling more resilient applications.

Here’s how it works:

• When a DDL operation is performed (say, altering a column’s data type or dropping an index), Db2 analyzes which SQL statements are affected.
• Only those specific statements are marked as invalid.
• When the package is next executed, only the invalidated statements will trigger automatic rebinds (or failures, depending on your setup).
• The unaffected statements remain executable without interruption.

This shift significantly reduces the scope and impact of invalidation events, particularly for applications with large packages that include a variety of different SQL access paths.

Why It Matters

From a DBA's perspective, this change brings several key advantages:

1. Reduced Outages: Applications are less likely to experience failures due to widespread invalidation. If only one statement is invalid, the rest of the application can continue running.
2. Improved Performance Management: It’s easier to isolate performance impacts and address only the affected statements.
3. Smarter Rebind Strategy: With only the necessary statements marked invalid, DBAs can delay or prioritize rebinds more strategically.
4. Support for Continuous Delivery: Statement-level invalidation supports the DevOps and agile models that many enterprises are moving toward, where small, frequent changes are the norm.

Important Considerations

While this enhancement is a welcome one, it’s important to note that it is only available in Db2 13, with Function Level 500 (V13R1M500). Make sure your system is properly configured to take advantage of this behavior.

Additionally, the ability to diagnose which statements have been invalidated requires careful monitoring. Dynamic tracing (e.g., IFCIDs) can help track and respond to invalidation events.

A good tracing setup to consider would include starting the following IFCIDs:

• IFCID 217 to detect the triggering DDL.
• IFCID 316 to see which package or specific statement was invalidated.
• IFCID 31 and 22 to trace follow-up activity (rebinds or PREPAREs).

Also, it is worthwhile to note that application developers and DBAs should continue to coordinate DDL changes carefully, even with this added capability.

Final Thoughts

Statement-level invalidation might sound like a small tweak under the hood, but in practice, it represents a significant leap toward more granular, less disruptive database management. For organizations running mission-critical workloads on Db2 for z/OS, this enhancement helps pave the way toward more agile operations without sacrificing stability.

As always, staying on top of these kinds of changes is part of the evolving role of the modern DBA. And in the world of Db2 for z/OS, precision matters—especially when it comes to maintaining performance and availability.