Oracle Dips A Toe Into IBM’s EBCDIC World - IT Jungle

August 24, 2026

IBM’s Ted Codd may have invented the relational database back at the Almaden Lab in the early 1970s, but it was Larry Ellison’s Oracle that offered the world the first wildly commercially successful RDBMs. Technically, the System/38 was announced, with its integrated relational database, before the first version of Oracle was announced.

Since then, Oracle and IBM have competed intensely to win and run transactional database workloads for some of the biggest enterprises around. But there was always one key difference between the two companies’ offerings: Oracle used an ASCI character set while the IBM midrange and mainframe systems relied on EBCDIC.

That key difference is beginning to change. Starting with Oracle AI Database 26ai, Oracle is now offering support for EBCDIC character encoding. The Oracle database not only supports EBCDIC-to-ASCI character conversion, but it also preserves the EBCDIC binary ordering, which has been a significant barrier to successfully migrating database workloads off IBM Big Iron in the past. Armed with this new capability, Oracle says IBM i and System Z customers can finally migrate their EBCDIC data to the Oracle database without losing critical functionality.

The EBCDIC-ASCII divide is as sharp a dividing point as you can find in modern computing. ASCII, or American Standard Code for Information Interchange, traces its roots back to the early 1960s, where it was developed by an IBM engineer from seven-bit teleprinter codes that were created from even earlier telegraph codes. ASCII offers a set of 95 printable characters and 33 control characters, for a total of 128 code points, which became the first 128 code points for standard Unicode. The vast majority of computers today use an ASCII character set.

EBCDIC, which stands for Extended Binary Coded Decimal Interchange Code, is a fundamentally different encoding regimen. It was developed by IBM to denote numbers, characters, and other symbols for use on the System/360 mainframe that launched in April 1964. The encoding system, which descended from six-bit punch card systems, allows for up to 256 unique values and continues to be used today only on IBM i and System Z machines.

The use of the EBCDIC character set by the IBM midrange and mainframe machines today represents one of the primary differences between Big Blue’s big iron systems and the rest of the computing world. All of the software developed to run on IBM i and System Z is designed to store data using EBCDIC encoding. There have been various attempts over the years to migrate EBCDIC data to ASCII systems. Some of these may have succeeded through brute force, but so far there have been no elegant solutions to this serious technical hurdle.

That may be starting to change. According to Michael Yau, the vice president of Oracle database globalization engineering, accurate character encoding conversion alone is not sufficient to preserve EBCDIC compatibility when migrating

“Many legacy EBCDIC applications, such as those written in COBOL, implicitly rely on the EBCDIC binary ordering defined by IBM EBCDIC code pages,” Yau writes in a recent blog post on the Oracle website. “SQL predicates that compare character values, perform range searches, or sort query results often assume this ordering. After migration to an ASCII-based Oracle AI Database character set, these same SQL statements can produce different results – not because the data changed, but because the database’s default binary ordering follows that of the ASCII-based database character set rather than the source EBCDIC code page.”

Oracle previously attempted to get around this technical barrier by using linguistic collations that attempted to match the binary ordering that IBM uses with its EBCDIC encoding. However that was not sufficient to overcome the deep differences between ASCII and EBCDIC systems. According to Yau, the Oracle AI Database 26ai implements client character sets based on IBM’s Character Data Representation Architecture (CDRA) code page definitions. This extra step provides source-to-target character mappings that are compatible with IBM’s published standards, thereby “enabling accurate and predictable character encoding conversion during data migration and subsequent database client/server communication,” Yau writes.

Yau says that each built-in emulated EBCDIC binary collation “is generated specifically for its associated IBM EBCDIC code page, reproducing its binary ordering. As a result, SQL comparison and ordering operations can preserve the behavior expected by many legacy EBCDIC applications with minimal or no SQL changes after migration.”

The built-in EBCDIC binary collations offer three advantages over other migration techniques, according to Yau. First, they are built into the Oracle AI Database and require no customization or maintenance. Second, they are supported on Oracle Exadata and Oracle Autonomous Database, where customized collations are not supported. Lastly, they implement EBCDIC binary ordering directly, avoiding the complexity, storage overhead, and performance costs associated with linguistic collations.

“Successful mainframe re-platforming depends on preserving EBCDIC compatibility after migration—not only the integrity of migrated character data, but also the application semantics that existing applications depend on,” Yau writes. “Whether the destination is an on-premises deployment or one of Oracle AI Database’s cloud deployment models, organizations can modernize mission-critical workloads while preserving EBCDIC compatibility.”

This certainly should get the attention of IBM and its midrange and mainframe customers. While EBCDIC-to-ASCII character conversion is not the only barrier preventing IBM i and System Z customers from leaving their “legacy” homes, it has been a significant one. If Oracle’s new technique is as good as it claims, then this barrier is effectively gone.

Of course, whether IBM i and System Z shops want to ditch IBM for Oracle is another question. Jumping out of the Big Blue pot and into the Big Red fire may bring with it a new set of conditions and dependencies, which should be studied closely before making a move.

推荐订阅源

Comments for IT Jungle

RELATED STORIES