Oracle 26ai speaks EBCDIC now. Your RPG code doesn't care

Oracle shipped something in AI Database 26ai that IBM i and mainframe shops have wanted for about thirty years: the database now sorts EBCDIC data in EBCDIC order. Not approximately, not through a hand-rolled linguistic collation, but properly, with built-in collations generated per code page.

It is good engineering aimed at a real problem. It also does close to nothing for the actual cost of an IBM i migration, and the coverage so far has not said that out loud.

The whole feature in one query

Oracle’s own documentation has the clearest possible demonstration. Create a table with a name column, insert five names, then run this:

SELECT ename FROM emp4 WHERE ename > '0' ORDER BY ename;

With a standard COLLATE BINARY column, you get all five rows back. Change one thing, declare the column COLLATE BIN_IBM37, and the identical query returns no rows at all.

That is not a bug. In EBCDIC, digits have higher byte values than letters, so 'Clara' > '0' is false. In ASCII, digits come first, so it is true. Thirty years of COBOL and RPG has been written on top of that assumption, usually without anyone writing it down. A predicate like WHERE product_code >= '0' was a perfectly idiomatic way to filter out alphanumeric codes on an IBM platform. Move the data to an ASCII database and that query silently starts returning rows it never returned before. Nothing errors. The report is just wrong.

That class of failure is why database migrations off IBM iron have historically blown their budgets in testing rather than in cutover. Oracle solving it is genuinely useful.

What actually shipped

Two separate things, and they are worth keeping apart.

CDRA-compatible client character sets. Twenty-one of them, with Unicode mappings that follow IBM’s Character Data Representation Architecture definitions rather than Oracle’s older approximations. Oracle is explicit that the older sets got things wrong: WE8EBCDIC37 mapped both 0x15 and 0x25 to U+000A, where the CDRA-accurate mapping sends 0x15 to U+0085.

These are client-only. You cannot make one your database character set. They exist so SQL*Loader, external tables, and DBMS_LOB can read source data correctly on the way in.

Emulated binary collations. One per code page, named BIN_IBM37, BIN_IBM1140, BIN_IBM500, and so on. These arrived in Release Update 23.26.2, not in the base 26ai release, which is worth knowing before someone tells you their 26ai instance already has it.

The code page list matters more than anyone has reported. All 21 are single-byte. The European set covers IBM37, 273, 277, 278, 280, 284, 285, 297, 500, 875, and the euro variants 1140 through 1148. Middle Eastern adds IBM420 for Arabic and IBM1026 for Turkish.

Two things follow from that list. First, IBM37 is CCSID 37, the default on a US-configured IBM i, so a typical American shop’s data is in scope. Second, there are no double-byte code pages at all. Nothing for CCSID 5035 or 930 or 939, nothing for Korean, nothing for Chinese. If you run an IBM i in Japan, this release gives you zero.

Credit where it is due

You could always reproduce EBCDIC ordering in Oracle by customizing a linguistic collation. It worked badly. Linguistic collations generate collation keys much longer than the source values, so the linguistic indexes needed to support them ballooned in size and cost. You were applying linguistic machinery to what is fundamentally a byte-comparison problem.

An EBCDIC binary collation is a byte comparison, so Oracle implemented it as one. The new collations generate keys that do not exceed the length of the original values, which keeps index sizes comparable to standard binary indexes. And because they are built in rather than customized, they work on Exadata and Autonomous Database, where custom locale data is not supported at all. For anyone whose migration target is Oracle’s cloud, that second point is the one that actually unblocks the project.

This is the right fix, done the right way. The problem is what happens next.

The sentence in Oracle’s own docs that nobody quoted

Chapter 12 of the Globalization Support Guide is titled “EBCDIC Emulation for Mainframe Migration.” It walks through migration strategy, target character set selection, and collation deployment across four sections. It does not mention IBM i once. Every strategy example is written for z/OS.

Then there is this, verbatim from section 12.1.2:

Because Oracle no longer supports Oracle Database Client software on IBM EBCDIC-based platforms, such as IBM z/OS, unchanged applications require a third-party translation layer.

IBM i is an IBM EBCDIC-based platform. Oracle’s route to it has historically been gateway products rather than a native client. So if your plan was to keep applications running on the Power box and point them at Oracle, you are buying a translation layer from somebody, and that layer has to use character set mappings compatible with the ones you used for the initial load or you have introduced a second, subtler version of the problem you just paid to solve.

The “IBM i customers can now migrate” framing came from press coverage, not from Oracle. Oracle said mainframe, repeatedly, in the chapter heading.

Record-level access is the wall in any IBM i migration

Oracle names exactly two migration strategies. Both are awkward on IBM i, and the first one is worse than it looks.

Data-only migration moves the data while applications keep running on the source platform in EBCDIC mode. Oracle’s own condition on this: it “requires that the source data is stored in a relational database and accessed with SQL, allowing applications to continue to access data in the same way.”

Read that condition against a real IBM i application. A large share of production RPG does not use SQL. It uses native record-level access, CHAIN and SETLL and READE and WRITE against DDS-described physical and logical files. That is a Db2 for i capability wired into the operating system. There is no Oracle equivalent, no gateway that makes a keyed logical file appear over the wire, no translation layer that turns a CHAIN into a fetch. Every file your programs touch that way has to be converted to SQL access before Oracle is even reachable.

At which point you are rewriting the application, which is Oracle’s second strategy, described as “completely rewritten, for example, moving COBOL logic to Java or another language.” The character set work is a rounding error inside that project. If you want the unvarnished version of what those projects actually cost and how they actually go, we wrote it up in what really happens when IBM i shops migrate.

The landmines further down the chapter

Assume you clear the access problem. Oracle documents several more things that will find you.

Binary data in character fields. Source code pages contain byte values that map to no character. Oracle’s example is code page 424, which leaves 38 byte values undefined. Any value containing one of them cannot be converted, and the fix is a customized source character set plus a third-party utility to pre-convert files before loading. A related problem, duplicated codes, arises where a code page maps two byte values to the same Unicode character, and a round trip silently collapses the distinction. Stuffing packed or binary data into alphanumeric fields is an old IBM i habit. Expect to find some.

SQL that changes meaning. CHR, ASCII, UTL_RAW.CAST_TO_VARCHAR2, UTL_RAW.CAST_TO_RAW, and DUMP all need review. Oracle’s example: CHR(67) returns ‘ä’ in code page 500 and ‘C’ in every ASCII-based character set.

Hashing and encryption across the wire. Encrypted and hashed values do not undergo client-server character set conversion. Encrypt on one side and decrypt on the other and you get the wrong encoding. Hash the same string on both sides and the values will not match. Oracle’s guidance is to do it entirely on one side, which may mean changing where your application does it.

Collation cost. Emulated collations use more resources than standard BINARY, and standard binary indexes cannot serve a predicate that uses one. You need a linguistic index or a data-bound column collation, applied deliberately to the columns that need EBCDIC ordering and nowhere else.

What an Oracle migration actually costs

Oracle Database Enterprise Edition lists at $47,500 per Processor, or $950 per Named User Plus with a 25 NUP per Processor floor, on the Technology Global Price List effective April 16, 2026. Real negotiated pricing runs well below list, but the direction is the point.

Db2 for i came with the operating system. There was no separate database line item, no processor metric to argue about, no audit exposure on a database you already paid for. Whatever the migration saves you, it does not save you that.

Bottom line

Oracle fixed a real problem properly, and if you are running z/OS with DB2 and a COBOL estate you are already committed to rewriting, this removes a genuine obstacle from your path.

For IBM i, character-set fidelity was never the expensive part. The expensive parts are the RPG, the record-level access, the DDS-defined files, the display files, the CL that glues it together, the journaling and commitment control, and the three people who understand why the order-entry program does that strange thing in the pricing routine. Oracle 26ai addresses none of them. It addresses a footnote, and it addresses it well.

So when a vendor or a consultant puts this announcement in a slide deck as evidence that leaving IBM i just got easier, ask which of those six items it touches. Sit through the answer. Then go read IBM’s own 810-page modernization Redbook, which is free, written for your platform, and considerably more honest about what modernization involves.

The uncomfortable truth underneath all of this is that the hardest asset to migrate was never the data. It is the knowledge, and it is walking out the door on its own schedule. If you want a practical way to capture it while you still can, that is what the IBM i AI Field Guide is for.

Frequently Asked Questions

Does Oracle AI Database 26ai support IBM i data?

It supports the character encodings IBM i uses. The 21 new client-only EBCDIC character sets include IBM37, which is CCSID 37, the default on a US-configured IBM i. Oracle’s documentation for the feature is written for z/OS mainframe migration and does not mention IBM i anywhere.

What is an emulated EBCDIC binary collation?

It is a sort order inside Oracle that reproduces the byte ordering of a specific IBM EBCDIC code page. In EBCDIC, letters sort before digits and lowercase sorts before uppercase, the opposite of ASCII. Emulated collations let migrated SQL return rows in the original order without rewriting the queries.

Can I run RPG programs against an Oracle database?

Not with native record-level access. CHAIN, SETLL, and READE against DDS-described files are Db2 for i operations with no Oracle equivalent. Programs using embedded SQL can be repointed with work, but any file touched through record-level access has to be converted to SQL first.

What does Oracle Database Enterprise Edition cost?

List price is $47,500 per Processor or $950 per Named User Plus with a 25 NUP per Processor floor, per Oracle’s Technology Global Price List effective April 16, 2026. Db2 for i, by contrast, is included in the IBM i operating system license.