DEV Community: Jay

I Rebuilt Our FTP Layer on IBM i — And It Fixed Problems I Didn't Know We Had

Jay — Wed, 29 Jul 2026 18:04:24 +0000

What happens when you replace twenty years of ad-hoc scripts with one framework

Every IBM i shop I've ever worked with has the same thing tucked away somewhere: a folder of CL programs that do FTP.

Not one. Not two. Dozens.

Some of them were written when the current network admin was in high school. Some have the password sitting in clear text, one line below an FTP command. Some of them ran fine for fifteen years and nobody touched them because touching them is scarier than leaving them alone. A few of them died quietly overnight last Tuesday and nobody noticed until the morning report was missing.

That's what this project started from. Not a grand modernization strategy. Not a compliance directive. Just the growing feeling that what we had was a very polite kind of disaster waiting to happen.

The pile

If you've lived this, you already know the shape of it. But for anyone who hasn't, here's what the "pile" actually looks like in a typical IBM i shop:

Clear-text passwords in CL source members. Anyone with read authority on the source file can see them.
No audit trail. Who created the script? Who last changed the destination path? Nobody knows. You display the source and hope the comments are honest.
No record of what ran when. If Tuesday's file didn't arrive, you're opening spool files and piecing together what happened from raw FTP output.
No retries. If the remote server bounced you once, the job failed and you got an email at 3 a.m. — assuming the email worked.
No recovery. If the FTP crashed mid-transfer, the production file was already half-overwritten. Good luck.
No way to disable a broken interface without editing production source. So nobody disables anything.

Everyone knew. Everyone had a story about "that one time." Nobody had the time to fix it all.

Deciding to actually do it

I started with what I thought was a small fix. One of our FTP pulls from a mainframe kept failing on Sundays. I opened the CL, fixed the timeout, went to save, and saw the password in the source. Not hashed. Not referenced. Not pulled from a data area. Just sitting there in plain CL, in a source file that half the shop could read because that's how the whole library was set up fifteen years ago.

I fixed it. Then I opened the next CL. Same thing.

I looked at the list. Dozens of these things. Interfaces to a mainframe, to UNIX boxes, to a cloud SFTP gateway, to a vendor's SFTP. All with their own idea of what "error handling" meant. All with their own password, right there in the source.

You know that moment where you stop trying to fix the broken thing and start trying to replace the category of thing? That was that moment.

Why FTP, and not an API

The obvious question, if you don't live on IBM i: why keep FTP alive at all? Why not just replace it with REST calls, or a message queue, or literally anything from this decade?

Because I don't control the other end.

The counterparties on these transfers are a mainframe that's been running since before I started, a handful of UNIX boxes owned by other teams, a cloud SFTP gateway, and vendor systems whose integration options begin and end with "here's your SFTP login." None of them are going to stand up a REST API for me. Some of them can barely be asked to rotate a password. FTP/SFTP isn't a design choice on my side of the fence — it's the only door that exists on the other side.

So the goal was never "get off FTP." It was "stop treating FTP as a place where anything goes." Where I do control both ends — internal services, systems I own — I use APIs, and that's a different, easier problem. This project was specifically about the transfers where FTP is the only option and the only thing standing between "reliable" and "whatever that CL happened to do in 2011" is whether someone bothered to build a framework around it.

That distinction mattered more than anything else in scoping this. I wasn't competing with modern integration patterns. I was making the legacy pattern I was stuck with behave like one.

What these transfers actually move

It's worth being concrete about what's riding on this, because "FTP framework" sounds abstract until you see what's actually flowing through it.

The ERP itself runs on the IBM i. Around it sits a mainframe that's still the system of record for a slice of transactional data predating the ERP, a warehouse management system on its own platform, EDI exchanges with vendors and trading partners, and a handful of internal reporting feeds. None of these systems talk to each other natively — the FTP layer is the connective tissue. Nightly extracts pulled in for the ERP to consume. Outbound files pushed out for the warehouse system to pick up. EDI documents exchanged with partners. Inbound price and inventory files landing from vendors.

None of it is glamorous. All of it is load-bearing. If the inbound inventory feed doesn't land by 4 a.m., the warehouse is working from yesterday's numbers. If the outbound order file doesn't reach the vendor, nothing ships. This is the plumbing that makes otherwise-unrelated systems agree with each other.

That's what made "just harden the FTP layer" worth three weeks of evenings. It wasn't a nice-to-have. It was the seam where every other system touched every other system.

The approach

I wasn't trying to build a platform. I wasn't trying to win an architecture award. I wanted one thing: take all of this and consolidate it into a single framework that an operator can configure without touching source code, that logs everything, that encrypts credentials, and that doesn't silently half-overwrite production files when something goes wrong.

Three layers. That's it.

Maintenance — a subfile UI. Operators define transfers by filling in fields: host, port, remote path, local file, pre/post commands, retry counts, retention. Passwords go in once, encrypted.

Execution — one program that reads the config, acquires a lock, runs the transfer, validates what came back, logs everything, and updates status.

Housekeeping — scheduled retention cleanup. Archives age out automatically according to rules the operator set when they defined the interface.

A small set of objects overall. A handful of physical files for the data model. Two service programs (one for encryption, one for logging). Two main programs, a retention job, and a CL wrapper for operator inquiries, plus display and printer files and a key data area.

About three weeks of evenings, once the design settled. The hard part wasn't the code. The hard part was all the things I didn't realize needed to be solved.

Pre and post commands — the escape hatch

Not every interface is "connect, get file, disconnect." Some need something to happen right before or right after.

A vendor drops a zipped file — it needs unzipping after it lands, before the ERP job that reads it ever runs. A file needs archiving under a different name before the transfer starts, because a downstream job is still reading the old one. Or the transfer is really just step one, and step two is submitting the ERP load job the moment the data is safely in staging, instead of waiting on a fixed schedule.

Rather than hardcode any of that into the engine, each interface can define its own sequence of pre-commands and post-commands — plain CL, run through the same command executor, in whatever order the operator sequences them:

Pre-commands  (before FTP): unzip inbound archive, rename prior file out of the way
Post-commands (after FTP):  submit the ERP load job, notify downstream job scheduler

They're stored the same way the rest of the interface is configured — as sequenced rows against that interface — so adding a step doesn't mean touching a compiled program. It means adding a row.

This is the piece that turned the framework from "a way to move a file safely" into "a way to move a file safely and then make something happen because it arrived." That second part ended up mattering as much as the first.

The problems I didn't know I had

This is the part that genuinely surprised me.

I went in thinking: centralize the config, encrypt the passwords, add logging. Done.

What I didn't expect was how many failure modes you uncover the moment you have one central place to look at them.

Jobs that crashed and left the world inconsistent

The old scripts would copy from FTP output straight into production. If anything failed partway — network blip, disk full, somebody killing the job — you'd end up with a partial file in production and no clean way to tell what happened.

The fix wasn't complicated, but it changed everything: always archive the current production file to a timestamped member first, always FTP into a dedicated staging file (never production), and only copy from staging to production at the end, as the last step. If anything fails before the final copy, production is untouched.

[archive current] → [clear staging] → [FTP into staging]
                  → [validate]       → [atomic swap to production]

The existence of staging changed the shape of the whole program. It meant I could validate before committing. It meant I could detect empty files. It meant I could compare record counts to the last run. It meant I could reject a transfer that looked wrong before it ate the existing data.

Stripped down to the shape of it (generic names, not our actual field names), the execution engine looks roughly like this:

// Never touch production directly — everything lands in staging first
archMbr = %char(%date(): *iso0) + %char(%time(): *iso0);

CPYF FROMFILE(prodFile) TOFILE(archLib/archMbr) MBROPT(*ADD);
CLRPFM FILE(stgFile);

ftpGet(host: user: password: remotePath: stgFile);

if recordCount(stgFile) = 0 and not allowEmpty;
  logAndHalt('E01: zero records received, expected data');
  return;
endif;

varPct = ((lastRecCount - recordCount(stgFile)) / lastRecCount) * 100;
if varPct > maxVarPct;
  logAndHalt('E02: record count dropped ' + %char(varPct) + '% vs last run');
  return;
endif;

// Only now does production ever get touched
CPYF FROMFILE(stgFile) TOFILE(prodFile) MBROPT(*REPLACE);

Nothing exotic. The whole trick is ordering: archive first, validate in staging, and let production be the last thing written, not the first.

Jobs that died without anyone knowing

Every run now opens with an entry in a history table marked running. When it finishes clean, it gets flipped to complete. If it fails, it gets failed.

Which means: if I see a row stuck in running but the job isn't running anymore, something crashed. The next run of that interface detects the orphan, logs it, and moves on. No manual cleanup. No lingering locks. No mystery rows.

It's a tiny pattern — one column and three status values — but it's the difference between "silent failure" and "the system tells you what happened."

-- opening a run
UPDATE ftp_history
   SET state = 'R', start_ts = CURRENT_TIMESTAMP
 WHERE run_id = :runId;

-- closing it out cleanly
UPDATE ftp_history
   SET state = 'C', end_ts = CURRENT_TIMESTAMP
 WHERE run_id = :runId;

-- on startup, before doing anything else: find yesterday's ghosts
SELECT run_id, iface, start_ts
  FROM ftp_history
 WHERE state = 'R'
   AND start_ts < CURRENT_TIMESTAMP - 1 HOUR;
-- anything this query returns didn't crash gracefully — it just crashed.
-- mark it 'F', log it, move on. No paging, no digging through spool files.

Jobs that retried forever

The old scripts didn't retry. If the server bounced you once, the whole job was a failure.

But sometimes the server just needs a second. So the new engine retries up to N times (per-interface, operator-configurable). Fine.

The interesting question was: what happens when retries run out?

Before, the job would just end in failure. But what if the operator is at their desk right now and could tell you something useful? What if they know the remote server is under maintenance and they want to skip this one and keep the rest of the batch going?

I wired it into the system operator message queue. When retries exhaust, the job sends an inquiry message: Retry / Skip / Cancel.

Retry — reset the retry counter, try again.
Skip — move on to the next record in the batch.
Cancel — shut down the entire run.

It sounds like an old-school pattern because it is one. But for an operator-monitored batch window, it's perfect. The job doesn't die unnecessarily, and it doesn't loop forever either.

Interfaces that were broken for weeks

The old scripts had no concept of "this interface is broken, stop trying." If a vendor changed their SFTP credentials on a Monday and nobody told you, your job would fail every night at 2 a.m. for a month, sending 30 failure emails. And on day 32 someone would finally read one.

New rule: if an interface fails N times in a row consecutively (configurable per-interface), auto-disable it. Send the escalation email once, not thirty times. The operator has to explicitly re-enable it, which means they have to acknowledge what broke.

It's a small change. It ended the 3 a.m. email storm inside the first month.

Transfers that overwrote good data with bad data

This is the one I'm most proud of catching.

Every interface stores the record count from its last successful run. On the next run, after FTP completes but before production is overwritten, the engine compares the new count to the last one.

If the drop is greater than a configurable variance percentage (say, 50%), it halts and raises an error. Production is untouched. The operator gets called in to look at it.

The number of times this has caught an upstream batch that only wrote half its data to the output dataset… I'm not going to tell you, because it's embarrassing that this used to just happen silently.

The audit trail we didn't have

The maintenance UI writes an audit record for every add, change, delete, or restore — field-level, with before/after values, user, timestamp.

Password changes are always logged as masked asterisks. The actual value is never, ever written anywhere other than the encrypted field in the config table. Not in the audit log. Not in error messages. Not in the spool. Not in the job log. Not in emails.

(Credential handling is its own rabbit hole and its own article. For now: I use AES-256-CBC with the IBM i Cryptographic APIs, key stored in a data area with exclusive authority locked to the service program, and the plaintext exists in memory for exactly the duration of the login call and is cleared the moment login returns. If you want the details, see my next post.)

Operational shape, after

The whole system compiles in a documented order — physical files first, then the key data area, then the two service programs, the CL wrapper, and finally the three main programs. Operators run it with simple calls:

call the maintenance program              // open the UI
call the FTP engine with (interface, code) // run one specific transfer
call the FTP engine with (interface, blank)// run all transfers for an interface
submit the FTP engine to a batch queue     // scheduled batch window
submit the retention cleanup on a schedule // nightly housekeeping

No source changes. No recompile. New interface? Add a row. Change a destination path? Change a field. Disable one temporarily? Flip a flag. Restore yesterday's archive? Option from the maintenance screen, auto-logged to audit.

What I'd say to anyone thinking about this

If you're on IBM i and you've got a pile of FTP scripts like the one I had, I'd gently suggest that you have more technical debt than you realize, and less work than you think it will be to pay it off.

A few things I learned that were not obvious going in:

Staging is the whole game. If production is never written to directly, half your failure modes stop being catastrophic and become "try again tomorrow."
A history table with a state column is cheaper than a monitoring system. A running row that never became complete or failed is a crash. That's it. You just discovered yesterday's broken job this morning instead of Friday.
Operators know things your program doesn't. A system-operator inquiry on exhausted retries sounds old-fashioned but is strictly better than either "fail silently" or "retry forever."
Variance detection catches bad upstream jobs. Not just your own problems. Your upstream batch also has bugs. Stop letting its bugs corrupt your files.
Auto-disable after N failures is a kindness. To you, to your team, to the operators who are tired of deleting 30 failure emails every Monday.

None of this is novel. Every pattern I used exists somewhere in the IBM i world, in some shop, written by somebody who already had the scar. The only thing that's new about this is that they're together, in one framework, running every FTP transfer we do.

What it feels like, afterwards

I'll tell you the thing I wasn't expecting.

After the rollout, the first week, we had a transfer fail. Remote server was down. The retry exhausted. The inquiry went out. Operator replied Skip. The run continued. The history table had one failed row and sixteen successful ones. The spool had a clean summary. The next morning, somebody logged in and saw the one red row, checked the remote status, clicked Retry from the maintenance screen, and it was done.

Nobody called me. Nobody sent a frantic email. No 3 a.m. page. The system told the operator what happened, they knew what to do, they did it.

That's what "modernization" actually looks like, I think, on IBM i. Not replacing the platform. Not rewriting everything in Java. Just taking the rough edges off the things that have been rough for twenty years, using the tools that are already there, and giving the people who run the business a reason to stop dreading their inbox.

Wrapping up

If you're in an IBM i shop and the word "FTP" gives you a mild anxiety response, you're not alone, and it's probably fixable. The platform has everything you need — SQL services, cryptographic APIs, subfile UIs, system-operator messaging, data areas, service programs. You don't need a new stack. You just need to decide the pile is the problem, and that one framework is the answer.

The credential encryption piece specifically — how I'm using the IBM i cryptographic APIs with AES-256-CBC, where the key lives, how it's rotated, and why you probably shouldn't write your own — is what I want to cover next. It's the part that should be easy and never quite is.

For now: if anyone from my old shops is reading this and you still have my old FTP scripts running somewhere, I'm sorry. I've done better since.

I am an IBM i practitioner working on modernization, integration, and warehouse systems.

# How I Encrypt and Use Credentials on IBM i

Jay — Wed, 22 Apr 2026 17:37:00 +0000

How I Encrypt and Use Credentials on IBM i

Because the password probably shouldn't be in the CL source

I'm going to say something a little uncomfortable.

If you work on IBM i and your shop has been around for a while, there is almost certainly a password sitting in clear text in a source member right now. Probably several. Probably an FTP password, maybe a database connection string, maybe a vendor API key. Maybe in a data area somewhere that doesn't have its authority locked down. Maybe in a CL that anyone with read authority on the library can display.

Not because your team is careless. It's just how things were done, and nobody has had the time to go back and fix it.

This post is the "how I finally fixed it" — specifically, how I'm storing and using credentials in a real production framework on IBM i, using the platform's own cryptographic APIs, without adding any new technology to the stack.

Why this is harder than it looks

The first time you sit down to solve "encrypt the password," a handful of bad patterns suggest themselves:

Base64 or a simple XOR — not encryption. Someone with read access can decode it in their head.
"I'll just hash it" — hashing is one-way. You can't log into FTP with a hash. You need the plaintext at the moment you use it.
Third-party encryption library — now you have a dependency, a license question, and a library running in your service program. You don't need any of that.
Hardcode a key in source — now the key is in the source. Same problem, one level deeper.

What you actually need is:

Strong encryption at rest — actual AES, not a scheme you made up.
A key that lives somewhere separate from both the ciphertext and the source — and with restrictive authority.
Decryption only at the moment of use — the plaintext exists in memory for as briefly as possible.
The plaintext never goes anywhere else — not a log, not a spool, not an error message, not the system operator queue, not an audit record.

IBM i has everything you need for all of this, and has for years. You just have to wire it up.

The tools IBM gave us

IBM i has a set of cryptographic APIs. The two you care about are the encrypt and decrypt primitives — they let you encrypt a block of data with a specified algorithm and key, and decrypt it back. They support the standard modern algorithms (AES-128, AES-192, AES-256) in the standard modes (ECB, CBC, OFB, CFB, CTR). They're callable from RPGLE. They've been part of the platform for nearly two decades. They're fine.

I'm using AES-256-CBC. AES-256 because there's no reason not to in 2026. CBC because it's straightforward, well-understood, and the per-encryption IV property is exactly what we want for "each stored password has a different ciphertext even if two users chose the same password."

You don't need to write the cipher yourself. You don't want to write the cipher yourself. The built-in APIs are the adult in the room.

Where the key lives

This is where most implementations get it wrong, so let me be deliberate about it.

The key is not in the source code. It's not in a physical file. It's not in the same library as the configuration table it encrypts. It's in an IBM i data area, authority-locked down.

Three things are happening when you set it up:

A 32-byte character data area. AES-256 needs a 256-bit key, which is 32 bytes. Nothing fancy.
Exclusive authority to public. Nobody gets to read this by default. Not end users, not developers, nothing.
Explicit grant to the service program's user profile. The encryption service program runs under a specific profile that has read access to the data area. Nothing else does.

If your service program uses program-adopted authority (the owner having read access to the key data area), you get the same effect — the service program can read the key, but the calling program and the calling user still can't.

This is the kind of thing IBM i is genuinely good at, and we forget to use. Object-level authority on a single data area is a more rigorous access control than most cloud secret managers offer out of the box. It just looks unfamiliar because we're used to reading about third-party vault products instead.

The encryption service program

The heart of this is a tiny service program. Two exported procedures. That's the whole API.

Encrypt — takes clear-text (say, up to 64 characters, which is plenty for a password) and returns a larger field containing a 16-byte IV followed by the ciphertext.
Decrypt — takes the stored field back and returns the clear-text.

That's the whole public surface area. Everything else is an implementation detail of those two procedures.

Inside Encrypt (sketch)

The real file is a couple hundred lines. The shape is:

dcl-proc Encrypt export;
  dcl-pi *n varchar(256);
    plaintext varchar(64) const;
  end-pi;

  // 1. Read the key from the data area
  //    (only this procedure, under its adopted authority,
  //    is allowed to do this)

  // 2. Generate a fresh IV (16 bytes, random)
  //    using the platform PRNG

  // 3. Build the algorithm descriptor for AES-256-CBC
  //    with this IV

  // 4. Build the key descriptor for our 32-byte key

  // 5. Call the encrypt primitive with plaintext,
  //    algorithm, key, result buffer

  // 6. Concatenate IV + ciphertext and return

end-proc;

Two things to note:

The IV is fresh every call. A new IV per encryption means that the same password encrypted twice produces two different ciphertexts. This is not optional; it's the security property CBC is trying to give you.

The IV is stored alongside the ciphertext, not hidden. The IV isn't secret — it just has to be unpredictable. Prepending it to the ciphertext means decryption doesn't need to know anything except the 32-byte key and the stored field itself.

Decrypt is the mirror image: slice off the first 16 bytes as the IV, feed the rest into the decrypt primitive with the same key and algorithm, return the plaintext.

Using it safely at the call site

This is the part that matters more than the crypto.

Here's how the execution program — the thing that actually performs the FTP transfer — uses a stored credential:

// 1. Read the encrypted password from the config table

// 2. Decrypt — plaintext now exists in a local field

// 3. Use it immediately — the login call is the only thing
//    that sees it

// 4. Clear it from memory the instant we're done

Four steps, in this order, no exceptions. The plaintext exists in memory for the duration of the login call and is cleared the moment login returns — whether the login succeeded or failed. The clear-text field never leaves this procedure.

What's deliberately missing:

No display of the plaintext. Obviously.
No log line that includes the password. Also obviously. But I've seen this in the wild.
No copy into a global field for "later use." There is no "later use."
No error message that includes the password. If the login fails, the error is "login failed for user X." That's it. The password is not the problem; the problem is whatever the server said back.
No audit record with the plaintext. The audit table logs changes to the encrypted field as masked asterisks. Always. If you ever need to prove that a password changed for compliance, you can see the timestamp and the user. You cannot see the value. That is the correct behavior.

If I could do one thing to make people's IBM i shops more secure, it would be: get everyone to stop logging the password "just for debugging, I'll remove it later." You won't. It'll be in a spool file for three years.

What about key rotation?

You need a plan for this before you deploy, not after.

My approach:

Generate a new 32-byte key. Store it somewhere outside IBM i for the duration of the rotation (a password manager, a sealed envelope — whatever your compliance model allows).
For each row in the config table: read the stored encrypted field, decrypt with the old key, re-encrypt with the new key, write back.
Update the data area to the new value.
Destroy the external copy of the new key.

This rotation is the kind of job that lives in a one-shot program that takes the old key and the new key as parameters and runs once. You throw it away after rotation. You don't leave it running anywhere.

There's a more elegant version of this where you have a key ID column next to each ciphertext and can support multiple keys in flight during a rotation window. For most shops, the simple "rotate all at once" pattern is fine — it takes a couple of seconds even with thousands of rows.

What else I'd watch for

A few things I've seen people get wrong, even with the encryption piece done correctly:

The password in a job parameter. If you submit a job with a clear-text password as one of its parameters, that parameter is visible in the job's submitted-jobs view and in the job log. Never pass a plaintext password as a parameter.

The password in a temporary physical file. "I'll just stage it in a work file for a second." No. Work files persist until they're cleared. If the job crashes, they persist longer. Don't.

The password in a user space. User spaces are visible with the right authority. If you wouldn't write the password to a physical file, don't write it to a user space.

Adopted authority for the wrong thing. If your service program adopts authority to read the key data area, make sure the programs that call it don't also adopt that authority. The whole point is that the key is only visible to one narrow thing.

Forgetting the clear. In RPG, local fields go out of scope when the procedure exits, and their memory will eventually be reused. "Eventually" is the issue — a failed login could leave the plaintext sitting in the activation group's memory until something else overwrites it. An explicit clear on the field as the last thing you do is cheap insurance.

Why this is worth doing even if nobody asks for it

No regulator is auditing your IBM i shop for clear-text FTP passwords. No CISO is going to find them unless they look. No application scanner is going to flag them because nothing runs against RPG source.

This is the kind of problem you either fix because you care, or you don't fix at all.

Here's the honest argument for doing it: the day someone does ask — because of a breach, an audit, a new vendor, a merger — the fix will take an afternoon if you've already built the pattern, and it will take months if you haven't. The encryption service program in my current framework is a couple hundred lines of RPG. The data area is one command to create. The authority lockdown is one command. Every program that uses a credential already goes through the Encrypt / Decrypt procedures. If I need to rotate the key, it's one program and fifteen minutes.

None of this is clever. None of it is new. IBM gave us these cryptographic APIs two decades ago and they've been sitting there, waiting.

Wrapping up

If you take one thing from this post, take this: passwords on IBM i should live in an encrypted field in a config table, encrypted with an AES-256 key stored in an authority-locked data area, decrypted by a small service program only at the moment of use, cleared from memory immediately after, and never written anywhere else. That's the whole pattern.

You don't need a vault. You don't need a new tool. You don't need to learn anything outside the platform. The cryptographic APIs are right there.

A framework I've been working on — an FTP integration layer I rebuilt from a pile of ad-hoc scripts — uses exactly this pattern for every credential it stores. It's a couple hundred lines of RPG and a data area. It's the cheapest, most durable security improvement I've made to an IBM i codebase in years. (I'll write that one up in a follow-up post.)

If you do this for one program, you'll end up doing it for more. And the next time someone opens a CL and sees a password in plain text, you'll notice, and you'll fix it.

That's the real goal. Not the crypto. The habit.

Jaya Krushna Mohapatra is a Warehouse Management Systems Architect focused on enterprise integrations, IBM i modernization, and scalable backend systems.

I Connected Claude to My IBM i - And It Changed How I Think About Legacy Modernization

Jay — Thu, 26 Mar 2026 14:34:23 +0000

What happens when you give an AI direct access to a system most people have never heard of

There's a weird disconnect in the AI conversation right now. Everyone's talking about coding assistants, AI-powered DevOps, intelligent dashboards — but almost all of it assumes you're running modern cloud infrastructure. Kubernetes, PostgreSQL, GitHub Actions. The usual stack.

Nobody's talking about what happens when your critical business system runs on IBM i.

I work with IBM i every day. Warehouses, supply chains, enterprise systems that process millions of transactions and have been running for decades. These systems aren't going anywhere. They're stable, they're fast, and they do exactly what they're supposed to do.

But they've also been left out of the AI conversation entirely. And I kept wondering — does it have to be that way?

The problem with IBM i and modern tooling

If you've worked with IBM i, you know the feeling. You're reading about some new tool or platform, nodding along, and then you hit the part where they assume everything lives in a REST API or a cloud database. And you think — okay, that doesn't apply to me.

The irony is that IBM i systems often hold the most valuable data in an organization. Decades of transaction history. Real-time inventory positions. Production schedules that run 24/7. But getting that data out — or even just asking questions about it — still involves signing into a green screen, navigating menus, running queries manually, and interpreting raw output.

It's not that the data isn't accessible. Db2 for i is a perfectly capable database. QSYS2 SQL Services have made an incredible amount of system information queryable through standard SQL. The access is there. But the experience of getting to it hasn't kept up with what's happening everywhere else.

When I discovered MCP

Earlier this year I came across the Model Context Protocol — MCP for short. It's an open standard that lets AI assistants connect to external tools and data sources. Anthropic published it, and it's gained traction quickly. The idea is simple: you define tools that the AI can call, and the AI figures out when and how to use them based on what you're asking.

The moment I understood how it worked, the wheels started turning.

What if I could write a handful of tools — run a SQL query, list active jobs, check system status, browse the IFS — and expose them to Claude through MCP? Not building a chatbot. Not training a model on IBM i documentation. Just giving an AI the ability to reach into the system and pull back real data.

So that's what I did.

How it works (without the complexity you'd expect)

The architecture is embarrassingly simple, which is part of what makes it powerful.

You write a small Python server that runs on your local machine. This server connects to IBM i through ODBC — the same driver you probably already have installed if you use ACS (IBM i Access Client Solutions). The server defines tools as Python functions, each with a description that tells the AI what it does.

That's the entire stack. Python on your PC, ODBC to IBM i, MCP to the AI. No changes on the IBM i side. No new programs to deploy. No RPG modifications. No service entries. Nothing.

The secret sauce, if there is one, is QSYS2 SQL Services. IBM has been quietly building out an incredible set of SQL-accessible system functions over the last several technology refreshes. Active job info, job logs, spool files, IFS statistics, system values, user profiles, message queues, data areas — almost everything you'd normally access through CL commands or green screen menus is now available as SQL table functions.

This means every tool in the MCP server is just a SQL query. Clean input, structured output. The AI gets JSON back instead of green-screen text, which it can actually interpret and reason about.

What it feels like to use

This is the part that genuinely surprised me.

I expected it to be useful. A faster way to run queries, maybe. A convenience layer. What I didn't expect was how much it would change the way I interact with the system.

You can ask things like:

"Show me all libraries that start with PROD and tell me how many tables are in each one."

And it just does it. Runs the query, counts the results, gives you a formatted answer. No navigating to WRKLIB. No typing SQL into STRSQL. Just a question and an answer.

Or:

"What's the system health looking like right now? Anything I should worry about?"

It pulls CPU usage, memory, disk capacity, active job counts — and then interprets them. Not just raw numbers, but context. "CPU is at 23%, well within normal range. Disk usage on ASP 1 is at 71%, which is getting up there — you might want to keep an eye on that."

The real magic happens when you chain things together in a conversation. You ask about active jobs for a specific user. Something looks odd. You say "check the job log for that one." It knows which job you mean from the previous response. Then you say "has this user had issues before? Check their message queue." And it does.

That kind of continuity — where context carries forward naturally — is something you can't replicate with traditional tools. Every green screen interaction is stateless. You close the screen, the context is gone. Here, the AI holds onto the thread and builds on it.

The tools that matter most

After using this for a while, I've found that certain tools get used far more than others.

SQL queries are the backbone. Being able to say "find all orders from the last 48 hours where the quantity is over 500" and get results instantly — that alone would justify the setup. But when you combine it with the AI's ability to interpret and summarize, it becomes something different. You're not just querying data, you're having a conversation about it.

System status is surprisingly useful. I used to check WRKACTJOB and WRKSYSSTS a few times a day. Now I just ask. And the AI remembers what "normal" looked like from previous checks, so it can flag when something changes.

Job logs are where the AI really shines. Reading job logs on IBM i is tedious — they're dense, full of informational messages mixed in with the important stuff. The AI is genuinely good at scanning through a job log and picking out the messages that matter. "There are 47 messages in this job log. Most are routine. But there's a CPF4131 at 14:23 indicating a file member not found, and a follow-up CPD0006 — that's likely your issue."

IFS browsing and file reading is the one I didn't expect to use as much as I do. Being able to say "show me what's in /home/myuser/exports and read the most recent CSV" is just faster than navigating the IFS through any other method.

Why QSYS2 is the unsung hero

I want to spend a moment on this because I think it's underappreciated.

IBM has been building QSYS2 SQL Services for years. Every technology refresh adds more. And the beauty of it is that it turns everything on the system into structured, queryable data. You don't need to parse command output. You don't need screen-scraping programs. You just write SQL.

For this kind of AI integration, that's everything. The AI needs structured data to reason about. Give it a blob of green-screen text and it'll struggle. Give it a JSON array of job records with named fields and it'll do exactly what you want.

If your shop hasn't explored what's available through QSYS2 lately, it's worth looking. The coverage now is extensive — far beyond what most people realize. It's one of the best things IBM has done for the platform in recent years, and projects like this show why.

What this means for IBM i shops

I'm not going to oversell this. It's not going to replace your operators. It's not going to automate your entire system. It's a tool.

But it's a tool that addresses something I've seen at every IBM i shop I've worked with: the knowledge bottleneck.

There are usually one or two people who really know the system. Who know which libraries matter, what the critical jobs are, where to look when something breaks. When those people are unavailable — or when they eventually leave — that knowledge walks out the door.

An AI that can query the system, interpret results, and carry context across a conversation doesn't replace that expertise. But it makes it accessible to people who don't have it yet. A junior developer can ask "what are the biggest tables in PRODLIB?" and get an immediate, meaningful answer. A manager can check on system health without learning CL commands. A new team member can explore the system conversationally instead of reading documentation that may or may not be current.

That accessibility matters. IBM i's biggest challenge has never been capability — it's been the perception that it's impenetrable. Anything that makes it more approachable is a win for the platform's long-term viability.

What I'd build next

This was a starting point. The obvious extensions:

Source member browsing — being able to read RPG or CL source through a conversation and have the AI explain what it does. Imagine onboarding new developers who can literally ask the AI "what does this program do?" while looking at the source.
Authority analysis — "who has access to this file?" is a question that takes too long to answer today.
PTF and system maintenance status — turning system administration checks into conversations.
Cross-referencing — "which programs use this file?" by querying object references through SQL Services.

The protocol makes this extensible. Adding a new capability is just adding a new function with a description. There's no framework overhead, no deployment complexity. The hardest part is writing good SQL, and if you're on IBM i, you're already doing that.

The bigger picture

I started building this because I was curious. I kept building it because it genuinely made me more productive. But what excites me most is what it represents.

For years, IBM i modernization has been framed as "move off the platform" or "rewrite everything." And both of those approaches are expensive, risky, and often unnecessary. The systems work. The data is valuable. The business logic is proven.

What MCP shows is that you can bring modern capabilities to IBM i without changing IBM i. You don't need to rewrite your RPG. You don't need to migrate your database. You don't need to replace anything. You just need to build a bridge — a thin layer that translates between what the AI expects and what IBM i provides.

QSYS2 SQL Services is one half of that bridge. MCP is the other. And the fact that you can connect them with a few hundred lines of Python — no middleware, no platform changes, no vendor contracts — is exactly the kind of pragmatic modernization that actually works in enterprise environments.

Wrapping up

I'm not naive about the limitations. There are security considerations — you need to be thoughtful about what you expose and to whom. There's the question of audit trails and compliance. And the AI will occasionally get a query wrong, just like any tool.

But the potential here is real. And it's the kind of potential that doesn't require permission from a steering committee or a six-month project plan. It's a Saturday afternoon experiment that turns into something you use every day.

If you're in an IBM i shop and you've been wondering where AI fits into your world, this might be the answer. Not a massive transformation initiative. Not a vendor platform. Just a conversation with your system that actually understands what you're asking.

Jaya Krushna Mohapatra is a Warehouse Management Systems Architect focused on enterprise integrations, IBM i modernization, and scalable backend systems.

I Connected Claude to My IBM i — And It Changed How I Think About Legacy Modernization

Jay — Thu, 26 Mar 2026 09:05:47 +0000

What happens when you give an AI direct access to a system most people have never heard of

Nobody's talking about what happens when your critical business system runs on IBM i.

But they've also been left out of the AI conversation entirely. And I kept wondering — does it have to be that way?

The problem with IBM i and modern tooling

When I discovered MCP

The moment I understood how it worked, the wheels started turning.

So that's what I did.

How it works (without the complexity you'd expect)

The architecture is embarrassingly simple, which is part of what makes it powerful.

That's the entire stack. Python on your PC, ODBC to IBM i, MCP to the AI. No changes on the IBM i side. No new programs to deploy. No RPG modifications. No service entries. Nothing.

This means every tool in the MCP server is just a SQL query. Clean input, structured output. The AI gets JSON back instead of green-screen text, which it can actually interpret and reason about.

What it feels like to use

This is the part that genuinely surprised me.

I expected it to be useful. A faster way to run queries, maybe. A convenience layer. What I didn't expect was how much it would change the way I interact with the system.

You can ask things like:

"Show me all libraries that start with PROD and tell me how many tables are in each one."

And it just does it. Runs the query, counts the results, gives you a formatted answer. No navigating to WRKLIB. No typing SQL into STRSQL. Just a question and an answer.

Or:

"What's the system health looking like right now? Anything I should worry about?"

The tools that matter most

After using this for a while, I've found that certain tools get used far more than others.

Why QSYS2 is the unsung hero

I want to spend a moment on this because I think it's underappreciated.

What this means for IBM i shops

I'm not going to oversell this. It's not going to replace your operators. It's not going to automate your entire system. It's a tool.

But it's a tool that addresses something I've seen at every IBM i shop I've worked with: the knowledge bottleneck.

What I'd build next

This was a starting point. The obvious extensions:

Source member browsing — being able to read RPG or CL source through a conversation and have the AI explain what it does. Imagine onboarding new developers who can literally ask the AI "what does this program do?" while looking at the source.
Authority analysis — "who has access to this file?" is a question that takes too long to answer today.
PTF and system maintenance status — turning system administration checks into conversations.
Cross-referencing — "which programs use this file?" by querying object references through SQL Services.

The bigger picture

I started building this because I was curious. I kept building it because it genuinely made me more productive. But what excites me most is what it represents.

Wrapping up

Jaya Krushna Mohapatra is a Warehouse Management Systems Architect focused on enterprise integrations, IBM i modernization, and scalable backend systems.

When HTTPAPI Fails: A Practical SOAP Integration Workaround on IBM i

Jay — Thu, 19 Mar 2026 04:25:43 +0000

A real-world approach to handling complex SOAP APIs when traditional IBM i tools fall short

I've been doing integrations on IBM i for a while now. Most of the time, HTTPAPI handles everything I throw at it — REST, SOAP, whatever. It just works.

But a few months ago, I hit a wall with a SOAP API that refused to play nice. And honestly, it took me longer than I'd like to admit to figure out why.

This is what happened and how I ended up solving it.

What went wrong

The setup was straightforward. Call a vendor's SOAP endpoint, send a request, get a response, process it in RPG. Standard stuff.

Except the response kept coming back wrong.

Connection was fine
HTTP 200 every time
But the response body was either empty or garbage

⚠️ In some cases, the request returns HTTP 200 but the response isn’t usable. In other cases, the request may not return a proper response at all—especially when working with older SOAP-based APIs.

When You Don’t Even Get a Proper Response

In some scenarios, the issue goes beyond receiving an unusable response.

With certain SOAP services—especially older or more rigid implementations—the request may fail before returning a meaningful HTTP response at all. This can show up as:

Connection resets
Timeouts
SSL handshake failures
Inconsistent or empty responses

These situations are often harder to debug because there’s very little feedback to work with. The request appears to fail silently, and it’s not always clear whether the issue is with the request structure, the transport layer, or compatibility between systems.

I spent a solid chunk of time convinced it was my SOAP envelope. Then I thought it was a namespace issue. Then maybe the headers. I kept tweaking things, and nothing changed.

The frustrating part? When I tested the exact same request in Postman, it worked perfectly.

The debugging spiral

I went through all the usual steps:

Rebuilt the SOAP envelope from scratch
Double-checked every namespace and header
Verified SSL certificates were in place
Compared raw payloads character by character

Everything matched. The request was identical. But HTTPAPI kept giving me bad responses while Postman returned clean data every time.

At some point I had to accept that the problem wasn't my request — it was somewhere in how the request was being sent.

Stepping back

Once I stopped trying to force HTTPAPI to work, the answer became pretty obvious.

The vendor's SOAP implementation was strict about certain HTTP behaviors — things like exact header ordering, specific TLS negotiation patterns, and chunked transfer encoding. HTTPAPI handles most of this fine for typical APIs, but this particular endpoint was picky in ways that were hard to control from RPG.

So I asked myself: what if I just let something else handle the HTTP part?

The fix: Java as a middle layer

I wrote a small Java program. Nothing fancy — maybe 80 lines. Its only job is to make the SOAP call and write the response to a file.

The flow looks like this:

RPG / CL
   ↓
Parameter file on the IFS
   ↓
Java program (handles the SOAP call)
   ↓
Vendor API
   ↓
Response file on the IFS
   ↓
Back to RPG for processing

RPG still runs the show. It writes out the parameters, kicks off the Java program, waits for the response, and processes it. The Java piece is just a bridge.

Why Java specifically

I've seen people suggest Python or Node for this kind of thing, and those would work too. I went with Java because it's already on every IBM i, no extra setup needed.

Java also gave me:

Predictable TLS behavior (the JVM handles negotiation well)
Full control over HTTP headers, including ordering
Proper chunked encoding support
Stack traces when things fail — which beats staring at a job log

The first time I ran it, the response came back clean. Same request that had been failing for days.

Keeping it reusable

I didn't want to hardcode anything, so the Java program reads from a parameter file:

ENDPOINT=https://api.vendor.com/soap
SOAP_ACTION=SomeAction
PAYLOAD=<Soap:Envelope>...</Soap:Envelope>
OUTPUT=/home/files/response.txt

Different API? Just change the file. The Java program doesn't care what it's calling.

The response gets written in a simple format:

HTTP Response Code: 200
Response Body:
<Soap:Envelope>...</Soap:Envelope>
STATUS: SUCCESS

RPG reads the status, grabs the body if it's good, and moves on. Clean and predictable.

This was part of what led me to try a different approach.

What I'd do differently

Looking back, I probably should have switched approaches sooner instead of spending so much time debugging HTTPAPI. The signs were there — identical requests working in other tools but failing from RPG.

I've since used this same pattern for two other integrations that had similar quirks. It's become a go-to option when the standard approach doesn't cooperate.

When this makes sense

I'm not saying stop using HTTPAPI. For most APIs, it's still my first choice.

But if you're dealing with:

SOAP endpoints that are strict about HTTP behavior
Responses that work everywhere except from IBM i
TLS issues you can't pin down
Debugging that's hit a dead end

...it's worth considering a hybrid approach. Sometimes the best thing you can do is let each tool handle what it's best at.

Wrapping up

This wasn't a glamorous fix. No new framework, no architectural overhaul. Just a small Java program sitting between RPG and an API that wouldn't behave.

But it solved a problem that had been eating up my time, and it's been solid since.

⚠️ Note on Java Setup

Make sure Java is properly available on your IBM i system.

A quick check is to run the JAVA command from a CL prompt or QP2TERM to confirm it executes successfully.

Also ensure your classpath and IFS paths are correctly set, as misconfiguration here can quietly cause failures.

If you've hit similar walls with SOAP on IBM i, I'd be curious to hear how you handled it. There's probably a dozen different ways to approach this — this just happened to be the one that worked for me.