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.

On The Importance of Choosing the Correct Data Type

Most DBAs have grappled with the pros and cons of choosing one data type versus another. Sometimes the decision is easy, whereas sometimes the decision is a little bit more difficult. In today's blog entry, we'll discuss both situations.

Data type and length are the most fundamental integrity constraints applied to data in a database. Simply by specifying the data type for each column when a table is created, DB2 automatically ensures that only the correct type of data is stored in that column. Processes that attempt to insert or update the data to a non-conforming value will be rejected. Furthermore, a maximum length is assigned to the column to prohibit larger values from being stored in the table.

The DBA must choose the data type and length of each column wisely. The general rule of thumb for choosing a data type for the columns in your tables is to choose the data type that most closely matches the domain of correct values for the column. That means you should try to adhere to the following rules:

• If the data is numeric, favor SMALLINT, INTEGER, BIGINT, or DECIMAL data types. DECFLOAT and FLOAT are also options for very large numbers.
• If the data is character, use CHAR or VARCHAR data types.
• If the data is date and time, use DATE, TIME, and TIMESTAMP data types.
• If the data is multimedia, use GRAPHIC, VARGRAPHIC, BLOB, CLOB, or DBCLOB data types.

But, of course, there are always exceptions. For example, what about social security number? That is a numeric column, but you won't be performing calculations using it. And, to format it correctly requires hyphens, which cannot be stored in a numeric data type. So, perhaps, SSN is an exception.

Leading Zeroes

Let's consider another typical situation: the desire to display leading zeroes. Maybe the application requires a four-byte code that is used to identify products, accounts, or some other business object, and all of the codes are numeric and will stay that way. But, for reporting purposes, the users want the codes to print out with leading zeroes. So, the users request that the column be defined as CHAR(4) to ensure that leading zeroes are always shown. But what are the drawbacks of doing this?

Well, there are drawbacks! Without proper edit checks, inserts and updates could place invalid alphabetic characters into the product code. This can be a very valid concern if ad hoc data modifications are permitted. This is rare in production databases, but data problems can still occur if the proper edit checks are not coded into every program that can modify the data. But let's assume that proper edit checks are coded and will never be bypassed. This removes the data integrity question (yeah, right!).

There is another problem that is related to performance and filter factors. Consider the possible number of values that a CHAR(4) column and a SMALLINT column can assume. Even if edit checks are coded for each, DB2 is not aware of these and assumes that all combinations of characters are permitted. DB2 uses base 37 math when it determines access paths for character columns, under the assumption that 26 alphabetic letters, 10 numeric digits, and a space will be used. This adds up to 37 possible characters. For a four-byte character column there are 374 or 1,874,161 possible values.

A SMALLINT column can range from -32,768 to 32,767 producing 65,536 possible small integer values. The drawback here is that negative or 5 digit product codes could be entered. However, if we adhere to our proper edit check assumption, the data integrity problems will be avoided here, as well. And we can always code a simple CHECK constraint to ensure that the code is always greater than zero.

DB2 will use the HIGH2KEY and LOW2KEY values to calculate filter factors. For character columns, the range between HIGH2KEY and LOW2KEY is larger than numeric columns because there are more total values. The filter factor will be larger for the numeric data type than for the character data type which may influence DB2 to choose a different access path. For this reason, favor the SMALLINT over the CHAR(4) definition.

The leading zeroes problem might be able to be solved using other methods. If you are using a report writer, most of them have quick methods of displaying leading zeroes. When using QMF, you can ensure that leading zeroes are shown by using the "J" edit code. Report programs can be coded to display leading zeroes easily enough by moving the host variables to appropriate display fields. Ad hoc access through other reporting tools typically provide a parameter that can enable leading zeroes to be displayed.

In general, it is wise to choose a data type which is closest to the domain for the column. IF the column is to store numeric data, favor choosing a numeric data type: SMALLINT, INTEGER, DECIMAL, or floating point. In addition, always be sure to code appropriate edit checks to ensure data integrity.

A DATE with DB2

What about dates? In my opinion, you should always use a DATE data type for date data. Why anyone would ever store a date or time in a DB2 table any other format than DATE, TIME, or TIMESTAMP is beyond me. But, oh, they do it all the time. And it causes all sorts of headaches. The benefits of using the proper DB2 data type are many, including:

• Ensuring data integrity because DB2 will ensure that only valid date and time values are stored
• The ability to use date and time arithmetic
• A vast array of built-in functions to operate on and transform date and time values
• Multiple formatting choices

Additionally, you have multiple built-in functions at your disposal for manipulating date and time data, but only when the data is stored as DATE, TIME, and TIMESTAMP data types. The time-related DB2 functions include CHAR, DATE, DAY, DAYOFMONTH, DAYOFWEEK, DAYOFYEAR, DAYS, HOUR, JULIAN_DAY, MICROSECOND, MIDNIGHT_SECONDS, MINUTE, MONTH, QUARTER, SECOND, TIME, TIMESTAMP, WEEK, WEEK_ISO, and YEAR.

I get questions all the time from folks who've stored dates using character data types; they ask all kinds of integrity and manipulation questions and I always, always, always start my reply with "You shouldn't have done that!"... and then I try to help them out, if I can. Don't fall into the trap of storing dates using anything but a DATE data type... you'll thank me later.

Summary

There is a lot more that can be said about choosing appropriate data types, but I think we've covered enough for today. The bottom line on data types is to use them to protect the integrity of your DB2 data and to simplify your job by taking advantage of DB2’s built-in capabilities. By choosing that data type that most closely matches your data you will be doing yourself, your systems, and your users a big favor.