DEV Community: Jay

Diagnosing a CA 2E-generated program that returns clean, throws nothing, and still doesn't do the thing

Jay — Thu, 03 Sep 2026 19:22:15 +0000

It Compiled. It Ran. Nothing Got Written.

Diagnosing a CA 2E-generated program that returns clean, throws nothing, and still doesn't do the thing — and why calling it directly is not the same test as running it for real

A compile error is, in a strange way, the easy case. The compiler stops you, points at a line, and you fix it before anyone downstream ever sees the problem. What actually costs people time on CA 2E work isn't the 1,600-message compile listing — it's the program that compiles clean, runs to normal completion, puts nothing in the job log worth reading, and simply doesn't do what it was generated to do. No message. No indicator. The job ends *COMPLETE. And the row you expected in the file isn't there.

This is a longer piece than the others in this set, on purpose. The failure mode itself isn't complicated once you've seen it a few times, but the list of things that can produce it is long enough that "just look at the code" isn't useful advice, and I want to actually walk through each one rather than wave at them.

As with the rest of this material — no real library, program, or field names. The scenario is generalized but the mechanics are not.

The setup

Somebody needs to test a function that a CA 2E model generated — say it inserts a record into a shipment history file given a handful of key values. Instead of running it through whatever normally triggers it — a menu option, a batch job, a display file transaction — they do the direct thing: find the generated program's object name, and call it straight from a command line, hand-typing the parameters.

CALL PGM(GENLIB/PGMNAME) PARM(('') ('CODE1') ('99') ('VALUE1') ('VALUE2'))

It runs. No escape message. No *ESCAPE in the job log, no dump, nothing red. Job ends normally. And then somebody queries the file it was supposed to write to, and the row isn't there.

The instinct at this point is to assume the program is broken — there's a bug in the generated logic, or the action diagram has a condition that's wrong. Sometimes that's true. Far more often, in my experience, the program did exactly what it was told, and what it was told wasn't what production actually sends it.

Why calling the generated program directly isn't the same test

Go back to how a CA 2E function actually gets invoked in production, and this stops being surprising. A generated function very often isn't called directly by whatever kicks it off — there's a CL program sitting in front of it, and that CL program is not just a thin pass-through. It's doing real work before the RPG program ever gets control: setting up file overrides so the RPG program's generic file references resolve to the correct member or the correct library, possibly starting commitment control for the unit of work, sometimes translating an external code into the internal key value the RPG logic actually expects, sometimes validating that the caller is even allowed to do this before bothering to call the program that does it.

Skip the CL and call the RPG program directly, and you've skipped all of that. The program you're testing is real. The environment it's running in is not the environment it was designed to run in. This is the single most common reason a direct call "does nothing" — not because the logic is wrong, but because the test wasn't equivalent to the thing that actually happens in production, and nothing about a clean compile or a clean run tells you that distinction exists.

I'd go as far as saying: if you're testing a generated function for the first time and you don't already know for certain that there's no CL wrapper involved, your first attempt should go through whatever the real entry point is, not around it. Confirm the real path reproduces the problem before you start debugging the RPG program in isolation. Otherwise you can spend an afternoon convinced a program is broken when the only thing broken is how you're calling it.

Hypothesis one: commitment control, and the rollback nobody asked for

This is the one that's caught nearly everyone who's worked with journaled files under commitment control on IBM i at least once, and it's worth understanding properly rather than just knowing "sometimes this happens."

If the file involved is journaled and the program (or something in the call stack above it) started commitment control for this unit of work, then a write to that file isn't final the moment the WRITE or UPDATE operation executes. It's pending, under a commitment definition, until something explicitly commits it. Here's the part that surprises people: if the program reaches last record indicator — *INLR on — without an explicit COMMIT having been issued, the default behavior is not to commit what's pending. It's to roll it back. Silently. No message says "rolling back your changes." The row you thought you wrote simply reverts, as far as any other job or query is concerned, and the job that did the writing ends completely normally, because from the system's point of view nothing went wrong — you just never told it to keep the change.

This is exactly the kind of thing a production CL wrapper handles and a bare, direct CALL PGM doesn't, unless the RPG program itself manages its own commit boundary internally, which not all generated functions do — some are written assuming the caller owns the transaction boundary, which is a completely reasonable design choice for a function that's meant to be one step inside a larger multi-file unit of work, and a completely unreasonable thing to assume when you're calling it standalone from a command line to test it.

How you actually check this, rather than guess:

Find out whether the file the function writes to is journaled at all. If it isn't, this hypothesis is dead immediately and you can skip to the next one.
Find out whether commitment control was active for the job that made the call. This is a job-level attribute; a job that never started commitment control can't have this problem, no matter how the file is journaled.
If both of those are true, the decisive test is simple: call it again, and this time issue an explicit commit yourself immediately afterward, in the same commitment scope, before the job ends. If the row shows up now, you've confirmed it, and the actual fix is either calling the function through whatever normally owns that commit boundary, or issuing the commit yourself as part of however you're driving the test.

I've also seen a variant of this that's more confusing to diagnose: the row is genuinely there, briefly, mid-transaction, and query it from a second session under the wrong isolation level and you'll either see it (uncommitted read) or won't (isolated read waiting on a lock that never resolves because the first job already ended and rolled back). If you're troubleshooting this interactively from two sessions at once, be aware that what you observe depends on which isolation level the checking query uses, and that alone can make the same bug look intermittent when it isn't.

Hypothesis two: the write landed somewhere you didn't check

If the production CL wrapper applies a file override — pointing a generic file name in the RPG program at a specific library, or a specific member, or a specific test copy of a file that exists for exactly this kind of ad hoc testing — and you call the RPG program directly without that override in place, the program still runs. It still executes a WRITE. It just resolves the file reference through whatever's on your own job's library list and override environment instead, which may not be the same target at all. The row might genuinely have been written. Just not where you looked.

This is worth checking before you conclude anything else, because it's fast to check and it's happened to me more than once: display the current file overrides in effect for your job before you call the program, and separately, check what the CL wrapper does when it runs normally — whether it applies an override of its own before invoking the RPG program. If it does, and you didn't replicate it, go look at the file your override-free call would have actually written to. Sometimes the row is sitting there exactly as expected, in a place nobody thought to check because nobody expected the write to land there.

Hypothesis three: the row exists, and the thing you queried can't see it

Related, but a distinct cause: you're looking at the right file, and the write genuinely happened and committed cleanly, but you're checking it through a logical file or a view with select/omit criteria that filters that particular row out. This happens more than you'd expect on files that have several access paths built for different purposes — a logical built for an active-orders screen that specifically excludes anything already flagged complete, for instance, would never show you a row you just inserted with a completed status, even though the physical write was entirely successful.

The fix here isn't a fix, it's just checking correctly: query the physical file directly, or a logical you know carries no select/omit restriction, before you conclude the write didn't happen at all.

Hypothesis four: the parameters you typed weren't the parameters the program needed

This one is specific to testing generated functions by hand, and it's easy to dismiss because "the call didn't error" feels like proof the parameters were fine. It isn't. A generated RPG program's parameter interface reflects exactly what the model's function definition says the parameters are — specific lengths, specific numeric types, zoned versus packed, a code that has to match one of a small set of valid values or the action diagram's own logic treats it as "not eligible" and takes a branch that does nothing on purpose.

If a CL wrapper normally sits in front of this function, part of what it may be doing is exactly this translation — taking a friendlier input and converting it into the exact shape the RPG program expects, sometimes including a lookup against another file to resolve an external code into an internal key. Skip that, hand-type a value that's the wrong length, the wrong justification, or simply doesn't match what a downstream condition is testing for, and the program can run start to finish, hit a condition that evaluates false, and reach *INLR having done nothing — correctly, according to its own logic, because as far as it's concerned you asked for something that isn't eligible.

The only reliable way to rule this in or out is to actually watch it happen: run the program under a source-level debugger, set a breakpoint just before the write operation you expect to fire, and look at the field values in front of you at that point. If you never reach that breakpoint, you've found your answer — some condition upstream of the write is evaluating false, and now you go find out why, with actual field values in front of you instead of guessing from the outside.

The order I'd actually check these in

Not because every case is the same, but because this order goes from cheapest-to-rule-out to most-invasive, and there's no reason to fire up a debugger before you've confirmed the basics:

First, reproduce it through the real caller, not around it. If the CL wrapper or the real entry point produces the same non-result, you've eliminated everything above that's specific to bypassing it, and you're looking at a genuine logic problem, not a test-environment problem. If the real caller works fine and only your direct call fails, stop looking at the RPG program's logic entirely — the problem is in what the direct call skipped, not in the function itself.

Second, if a journaled file and commitment control are anywhere in the picture, rule that out explicitly with a deliberate commit before you trust a negative result at all.

Third, check where the write actually went — overrides, library list, the member actually targeted — before assuming it went nowhere.

Fourth, check what you're using to verify the result — a filtered access path can hide a row that's genuinely there.

Fifth, and only once the first four are exhausted, get into the program itself with a debugger and watch the actual condition logic evaluate against the actual values it received.

I've seen people reach for the debugger first, because it feels like the thorough, technical thing to do. It's usually the slowest way to solve this specific problem, because three of the four most common causes have nothing to do with the code the debugger would show you. The debugger answers "why did this condition evaluate the way it did." It has nothing to say about a rollback that happened after the program already ended cleanly, or a write that landed in a file you weren't looking at.

The broader point, if there is one

A clean compile tells you the syntax is legal. A clean run with no error message tells you the operations that executed didn't fail. Neither one tells you the operations you expected actually executed, against the environment you expected, with the data you expected, and stayed committed after the job ended. Those are four separate claims, and a CA 2E-generated function — layered as it typically is behind a CL driver, sometimes behind commitment control, sometimes behind a translation step you never see unless you go looking for the wrapper — is exactly the kind of thing where testing it by calling the innermost piece directly quietly drops two or three of those four claims without telling you it did.

If something "worked, no errors" and the result still isn't there, the honest first question isn't "what's wrong with the program." It's "did I actually test the thing that runs in production, or did I test a piece of it in an environment nothing else ever puts it in."

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

1,619 Compiler Messages, Four Real Causes: A CA 2E to RPGLE Compile Reference

Jay — Wed, 02 Sep 2026 22:29:34 +0000

1,619 Compiler Messages, Four Real Causes: A CA 2E to RPGLE Compile Reference

What actually happens when a Synon model becomes a compiled RPGLE program — and how to read the wall of errors when it doesn't

CA 2E (Synon) does not write RPG. It writes a model — files, functions, action diagrams — and a code generator turns that model into RPG source, then a separate step turns that source into a compiled object. Most of the confusion people have converting CA 2E work to RPGLE comes from not knowing where the seam between those two steps is. This is a reference for that seam: the path from model to object, what it looks like when it breaks, and how to read a compile listing with over a thousand messages in it without treating each one as a separate problem.

No library names, program names, or field names below are real. They've been left out entirely rather than replaced with placeholders, because the mechanics and the error categories don't need them to make sense.

Two things to know before you touch a model

Generate and Create are different steps, and only one of them needs the model to be right.

"Generate" turns a function's action diagram into RPG source and writes it to a member. It does not compile anything. "Create" compiles and binds that source into an object. CA 2E's menu lets you do both in one submitted job, which is convenient right up until that job fails, because the failure message tells you almost nothing.

Target HLL "RPG IV" does not mean free-format.

This is the part that surprises people coming from a "just convert it to RPGLE free" mindset. Setting a function's target high-level language to RPG IV makes CA 2E generate traditional fixed-format RPG — column-based calculation specs, sequence numbers, no free-format delimiters. It compiles as an RPGLE member type, and ILE will bind it like any other RPGLE program, but the source itself reads like an older RPG dialect with a newer header. If you want genuinely free-format output, that is a second, deliberate step after the generated source compiles clean — never before. Free-format conversion tools rewrite syntax; they don't fix logic. Feed one a program that doesn't compile and you get free-format syntax wrapped around the same bug, which is now harder to spot because it looks new.

So the realistic pipeline is: model, then generate, then fixed-format RPG IV source, then compile clean, and only then — if you actually want free-format — convert the syntax. Not model straight to free-format RPGLE in one step. Nothing in the generator does that for you.

The path from model to object

1. Get the model on the library list. The generation commands need to find both the model itself and the separate generation library it automatically maintains alongside it. If the underlying product library isn't available, you get a blunt message before you even get near your own code, something to the effect of the product library not being installed for high-level-language generation.

2. Copy the model if you don't want to touch the real one. There's a menu option specifically for commands that copy a model, and the command behind it lets you copy from one model to a new one while telling it not to create any objects — just the definitions. That gives you a sandbox to generate and compile in without touching anything the real model owns.

3. Set the function's target language. Inside the copied model, find the function you're working on and set its target high-level language to RPG IV. This is a setting on the individual function, not on the model as a whole — different functions in the same model can target different languages.

4. Generate the function. From the screen that lists a model's functions, there's an option to generate. This writes the RPG IV source member into the model's generation library, whether or not anything gets compiled afterward. The member existing is not evidence the program works. It's evidence the generator ran.

5. Submit the model create request. There's a follow-on option that submits generation and compilation and binding together as one batch job.

If that job finishes clean, you have a working object and nothing below this line matters. If it doesn't —

When the submit job dies, stop debugging the submit job

The message you get back is short: a job identifier, and a note that it ended abnormally.

That's it. No compiler message, no line number, no indication of which of the several things inside a generate-then-compile-then-bind job actually failed. You can chase this through job logs and the model's own error lists, and sometimes that's the right call if the model itself is broken — a missing access path, an undefined function reference. But most of the time, the model is fine and the generated source has a problem the compiler would tell you about immediately, if you asked the compiler directly instead of through that wrapper.

You already have the source. The generate step wrote it, independent of whether the create step's compile succeeded. Go find it with the standard member-list utility, pointed at the generation library and the source file the generator writes to.

The member is sitting there — generated, uncompiled or compiled-and-failed. Compile it directly from that member list. Now you're not waiting on a batch job to tell you it died. You're looking at the actual compiler output, the same listing you'd get for hand-written source. That's the pivot: the moment the black-box submit job fails, drop out of the model layer entirely and work with the generated source like it's just RPGLE, because at this point it is.

This one compile threw:

Message Totals:
  Information (00) . . . . . . :    48
  Warning      (10) . . . . . . :     0
  Error        (20) . . . . . . :   995
  Severe Error (30+) . . . . . . :   576
  -----------------------------------
  Total  . . . . . . . . . . . :  1619

Sixteen hundred and nineteen messages on a program that, days earlier, had been generating and running fine somewhere else in the model's history. Nobody rewrote 1,619 things overnight. Something small broke, and the compiler reports every downstream consequence of that one thing as its own message.

Reading the listing without reading 1,619 lines

Don't start at the top. Two places matter first.

The final summary, shown above, tells you how bad it is in aggregate: mostly error and severe error, no warnings, means something structural, not a style nitpick.

The message-frequency section — the same compile listing groups every message by its ID and gives you a count. This is the part almost nobody scrolls down to look at, and it's the part that turns 1,619 lines into an actual to-do list. In this listing, ten distinct message types accounted for everything:

A handful of messages saying that all record formats for an externally described file were ignored or dropped due to error, and the file itself was ignored.
A handful more saying a file-name or record-name entry wasn't valid, so the input record was ignored.
A handful saying a record format name in an externally described file was already defined, so the format was ignored.
Then the bulk of the volume — hundreds of occurrences of "the name or indicator is not defined," hundreds more of "the field on the calculation specification is not numeric, so the specification is ignored," dozens of "the move operation has operands that are not compatible," dozens of "expression contains an operand that is not defined," and a couple of "the types on either side do not match in the EVAL operation."
Rounding it out, a few hundred lower-severity messages about matching-fields and control-level entries defaulting to blank because they weren't set to valid values.

Two message types, roughly ten occurrences between them, are root causes. Everything else — the other 900-plus occurrences — is the compiler dutifully reporting that fields it can no longer see are, in fact, no longer defined. Once a record format gets dropped, every field from that format that the program touches throws its own "not defined," and every operation built on that undefined field throws another message about incompatible types or non-numeric operands. One dropped file produces a hundred symptoms. Fix the file, and the hundred symptoms go with it.

This is the actual skill in triaging a CA 2E-generated compile: read the frequency table before the line-by-line, find the message types whose description describes a structural problem — a file, a format, a name resolution — fix those first, and recompile before touching anything the cascade produced. Chasing the cascade individually is how a five-hour fix turns into a two-day one.

The four root causes, described rather than named

1. The library list at compile time isn't the library list the model's own job used

The model's own submit job runs with its own library list, built from the model's configuration. When you compile the generated source yourself, you're using whatever library list your own session has — and if the physical and logical files the generated source references aren't resolvable from there, the compiler doesn't fail loudly. It fails quietly, reporting the file as ignored, and then reports every field from that file as undefined for the rest of the listing. This produces exactly the shape above: a couple of "file ignored" messages and hundreds of cascading "not defined" messages that look unrelated but all trace back to one file the compiler couldn't find.

The fix is to put the actual data library — the one holding the physical and logical files the function touches, not just the model's own libraries — on the library list before compiling standalone. This is the single highest-leverage thing to check first when a compile like this looks catastrophic.

2. A record format collides with itself

One message type in particular — a record format in an externally described file already defined, so the format gets ignored — shows up when the same format name resolves twice. Usually that's a leftover generated member from a prior attempt still sitting in the same source file, or two access paths on the same file generating under the same format name. Deleting the stale member and regenerating clean is faster than trying to patch around a duplicate definition.

3. The generated instruction references a name the file doesn't actually expose

Somewhere in the generated code, a read-by-key operation was pointed at the generator's own internal working name for an access path, rather than the actual key-list name that the underlying logical file exposes externally. Most of the time these line up and you never notice — the generator's internal label and the file's real key-list name happen to match. When they don't, the fix is a one-line swap of the operand to the file's real key-list name. You'd never find this by reading "the name or indicator is not defined" in isolation, since that message fires on dozens of unrelated lines too. You find it by noticing this specific line sits right next to the file that came back "ignored," and checking the logical file's actual externally-defined key-list name against what the generator wrote into the calculation.

4. Fields exist in the table, not in the format the program is reading

A program reads by key against a logical file — an index — rather than the physical file directly, which is normal; that's what indexes are for. But if a couple of fields exist on the underlying physical file and were never carried onto that particular logical file's externally described format, the generated program can reference them by name — because the model knows about the physical file — while the compiler, working only from the logical file's actual record format, correctly says they don't exist.

There are two honest fixes here. Either change which file the program keys off of, to one that does carry those fields, or confirm — actually confirm, not assume — that the values are already being retrieved elsewhere in the program from a different file, and only then drop the reference. In the case that produced this: both fields were already being pulled from two other files the program had open. The reference through the index was redundant, not load-bearing, so removing it was correct. If it hadn't been redundant, the right fix would have been changing which file the read targets, not deleting the field.

An estimation table that actually holds up

If you're scoping more than one or two of these, per-program time varies enormously by file usage, and a flat "X hours per program" estimate will be wrong in both directions. Track three numbers separately, because they don't correlate the way you'd expect: how long the conversion itself took, how long fixing the resulting compile errors took, and how much testing effort is still outstanding.

The first program in a batch is not representative of the rest. It takes the longest on both conversion and compile-fixing, because you're still learning the model's conventions and still learning which message types are structural versus cascade. The second and third go faster — not because the code is simpler, but because you've already built the pattern library for what a "file ignored" cascade looks like versus a genuine logic gap. A program with heavier file usage, or a display file involved, will cost more again regardless of where it sits in the sequence. Budget the first one generously and use it to calibrate, not to extrapolate.

The reference version of all this

Generate writes source. Create compiles it. They can run together in one submitted job, but they fail independently — know which one broke.
Target high-level language "RPG IV" gets you fixed-format RPG IV. Free-format is a separate, deliberate conversion step you run after the source compiles clean, never before.
When a submitted create job ends abnormally, don't dig through the job log for a reason. Go straight to the generation library, find the source the generate step already wrote, and compile it yourself. You'll get real compiler diagnostics instead of a batch-job status.
On a large error count, read the final summary and the message-frequency table before anything else. Look for structural message types — file and format resolution — before touching the hundreds of cascade messages they cause.
A file reported as ignored, or a format reported as already defined, are library-list and stale-member problems, not code problems. Fix those first; most of the rest disappears on the next compile.
A field the model knows about isn't necessarily a field the file format you're reading exposes. Read against the file that actually carries what you need, or confirm the value already exists elsewhere before you delete the reference.
Effort on the first converted program tells you almost nothing about the tenth. Track conversion time and compile-fix time separately per program if you're estimating a batch.

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

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.