3 (More) Foundational AI Capabilities for IBM i

Rick Hurckes, director of services at mrc, shares how AI can fill gaps in IBM i environments that used to be addressed with workarounds and tribal knowledge

Part 2 of 2

Earlier, I made the case that the best way to think about AI on IBM i isn’t to start with the use cases you want to build. Start with a simpler question: What can AI do that I currently cannot do with RPG and SQL?

Once you can name these foundational capabilities, you stop chasing the same three or four use cases everyone else is building and start seeing them all over your business.

Part 1 of this two-part series covered the first four capabilities: understanding unstructured input, writing language back out in context, reasoning across many systems at once and applying judgment to cases nobody coded for. Here are the remaining three.

1. Converting Between Formats Without Custom Code for Each One

Traditional format conversion requires building a translator for each pair: One parser for Vendor A’s invoice layout, another for Vendor B’s, a third for the customer who sends orders as Excel files. Every new format means new code.

AI doesn’t need a custom parser for each format. It reads the input, understands the structure and intent and maps it to whatever output format you need. One capability handles all of them.

This works in both directions. Unstructured input becomes a structured Db2 for i record. Structured data becomes a customer-facing email. A status code becomes a paragraph. An English support ticket becomes a Spanish response.

If you’ve ever written an RPG program just to parse one customer’s PO format into your order files, you know the pain. AI replaces that per-format custom code with one general capability.

Use case examples built on this foundation:

• Inbound vendor invoices arrive in dozens of different layouts. AI extracts line items from each, matches them against your PO records and creates structured AP entries, without a separate parser for each vendor.
• A customer sends an order as an email attachment, a PDF and a spreadsheet on three different occasions. AI handles all three the same way.
• An inbound support ticket arrives in Spanish. AI translates it, routes it to the right team and drafts a response in Spanish, all without your team needing to read the original language.

2. Reading and Explaining Code and Process

A lot of IBM i shops I work with have RPG programs written 15 or 20 years ago by someone who’s no longer with the company. Nobody fully understands what it does and nobody wants to touch it. The tribal knowledge walked out the door when the original developer retired. People just run the program and hope for the best.

AI reads that old code and can explain what the program does, what business rules are embedded in the logic and what would break if you changed a specific section. It reads the DDS for the physical and logical files the program references. It traces the call chain through service programs and modules.

Suppose a developer wants to change a field in a file. They ask, “What breaks if I change this?” AI reads every RPG program, CL, trigger, SQL view and logical file that references that field, and produces a complete impact analysis. How much time would that save?

Now, this doesn’t replace the need for good RPG developers. But, it means your developers spend their time building instead of reading archaeology. More importantly, it means the knowledge that’s trapped in old code is accessible to people who didn’t write it.

Use case examples built on this foundation:

• A developer opens a 2,000-line RPGLE member nobody’s touched in 10 years and asks, “What does this do and what business rules are in it?” AI reads the source, the copy members and the file DDS, and explains it in plain English.
• “What breaks if I change the order status field?” AI scans every RPG program, CL, SQL view, trigger and logical file that references the field and produces a full impact list in seconds instead of days.
• A new employee asks, “What’s our return policy for damaged shipments over $5,000?” AI reads the policy document stored in the IFS and answers with the specific clause, the approval hierarchy and the exception conditions.

3. Holding a Conversation With Memory

Traditional queries answer one question at a time. When you change the selection criteria, you must re-run the query and get a new result. Every question starts from scratch.

AI holds a conversation. For instance: “Show me Acme’s open orders.” “Which one is biggest?” “Why is it on hold?” “What should I do about it?” Rather than running 4 different queries, you have one continuous thread. Each follow-up builds on what came before. The AI remembers that you’re talking about Acme, remembers which order you drilled into and carries that context forward.

This sounds small but it changes how people interact with their IBM i data. Instead of knowing exactly which command to run or which screen to navigate to up front, they can think out loud. They can start with a vague question and narrow it down as they learn.

When I’ve shown this to IT directors who’ve been running IBM i shops for 20 years, the reaction tends to be the same. They start asking questions about their own data they’ve never asked before, because they’ve never had a tool that could follow the thread.

Use case examples built on this foundation:

• “Who’s past due over 60 days?” “How much does each one owe?” “Which ones have a history of paying late?” “Draft a collection email for the top 3.” Four questions, one thread, each building on the last.
• “Show me top 10 customers by revenue last quarter.” “Now just manufacturing.” “Compare to the prior quarter.” “Draft a summary for my boss.” The user refines as they think, just like they would talking to a colleague who knows the data.
• “Which products had margin decline this month?” “Focus on the top 3.” “What changed for product X?” “Was it cost or pricing?” “Show me the sourcing changes.” Each question drills deeper without losing context.

What This Means for Your IBM i Shop

These seven capabilities, the four in Part 1 and the three above, are what AI makes possible on top of the IBM i environment you already have.

The best part: It works with everything you already have. Your RPG programs still run the business logic. Your Db2 for i files still hold the data. Your IBM i security model still governs who sees what. AI fills the gaps around all of that … the gaps that have been handled by people, workarounds and tribal knowledge for the past 30 years.

Once you can name these seven capabilities, you stop waiting for someone to hand you a list of AI use cases. You start seeing them everywhere in your own shop.

---