A list of objects. That was all we wanted that morning, the contents of a library with the type, the owner and the creation date of every entry, available inside a .NET application.
On IBM i, the thing has a name, QUSLOBJ, and it does not surrender its result willingly. You first have to create a user space in QTEMP, call the API, then read that space back byte by byte to find, at offsets that only the IBM documentation spells out, the number of entries and their properties. And since the size of the result stays unknown until you have obtained it, you had better plan to start over with a larger space.
We published the full tutorial for this call in May 2025. Six steps, thirty-seven properties to map, around a hundred lines of C# at the end. Writing them meant reading the IBM documentation line by line, getting a few offsets wrong and starting again.
We put the same question to a coding assistant, with the IBM documentation on one side and, since V5, the NTi context file on the other, the one we now ship with the provider so that it does not invent a connection string or confuse CCSID with naming convention. A hundred lines or so were there within moments, checked and correct.
The tutorial has lost none of its usefulness, it has changed jobs: it no longer serves to write the code but to check the code you are handed. Keep that distinction in mind, it carries just about everything that follows.
The anecdote will surprise nobody any more, so widely has this kind of story circulated for two years. It says rather little about artificial intelligence and a great deal about the economics of IBM i software. Because that effort, repeated function after function, is exactly what a software vendor sells. Listing active jobs, reading the attributes of a user profile, walking through an output queue… every one of those gestures called for the same decoding work, and a tool worth the name adds up dozens of them. Nobody could seriously afford to pay that bill in house, so they bought instead. One vendor for terminal emulation, another for webfacing, a third for monitoring, a fourth for business intelligence. Each was selling less a set of features than months of IBM documentation already read on your behalf.
But what is left of that trade the day those months become hours?
Two layers, two prices
To answer honestly, you have to accept a rough but convenient distinction. Two layers of very different natures coexist inside a piece of software, and only one of them has just lost value.
The first is business knowledge. Net requirements calculation, discount terms by sales channel, backorder handling, the forty-seven special cases piled up since 1994 because an important customer asked for them. That layer lives with you, in your RPG programs and in the memory of your teams. But no machine can guess it, and its price has not moved by a cent.
The second is everything else. A web interface, a paginated grid, a form, an export, an authentication scheme, a REST endpoint, a container, a continuous integration pipeline... And, on IBM i, the interpretation of the structures we have just described. That generic part commonly accounts for four fifths of a tool's code, demands real skill and takes time. It simply has this particularity that it has already been written tens of thousands of times, which is why generative models handle it remarkably well today.
Now the software bought around an IBM i belongs almost entirely to that second layer, laid on top of a system that already exists. A monitoring tool is a reading of message queues and an interface to present them. Webfacing is a projection of DDS screens. In both cases the business value does not budge an inch, it stays in your partition.
Hence an answer less brutal than it looks. A vendor whose product draws on the first layer risks nothing, and the vertical ERP of your industry will sleep soundly for a long while yet. A vendor whose product sits entirely in the second is now selling something its customer can build alone. The trade-off shifts mechanically, without anyone needing to be blamed for it.
Putting it to the test
We would not have written these lines without testing them first. Several demonstration tools have come to life over recent months, all in .NET, all with the NTi provider and coding assistants, and all in categories that are sold under license today. No component installed on the IBM i side, in any of them. Here are two, picked at random from the demonstration: a message queue manager, and a library map.
QSYSOPR, one hundred and seventy-five messages, repeats grouped together, the last twenty-four hours of activity summed up in a single chart. The same queue, on a green screen, fits on twenty-four lines.
The ADHEDB field, present in two physical files, touches five programs before reaching a single screen. Four of them modify it, one reads it, none is left with undetermined usage.
We will say no more: this sort of thing is better shown than told, and better shown on your data than on ours. We are happy to arrange a demonstration for anyone who wants a sense of what has become possible to build, and how fast.
The whole system is an API
The QUSLOBJ story told at the start was not an isolated case. It holds for the entire system.
It is easily forgotten that IBM i is documented from end to end. Behind every screen, whether a 5250 session or a Navigator panel, behind every WRK command, there is an API published by IBM, with its name, its parameters, its return formats and its manual. Listing active jobs, reading the attributes of a profile, querying the state of the system, managing authorities, all of it is obtained through a program call in QSYS. The machine hides nothing and never has.
If almost nobody used them, the documentation was not to blame: the exercise was thankless, and our object list ranked among the easier ones. What automated reading of the manuals changes is the coefficient. These documents are public, structured and exhaustive, which is precisely the material language models render better than we do. On the .NET side, the call then keeps the shape of an ordinary signature.
var parameters = new List
{
new NTiProgramParameter("NTILOBJ", 10).Append("QTEMP", 10), // user space
new NTiProgramParameter("OBJL0400", 8), // data format
new NTiProgramParameter("*ALL", 10).Append("PAYLIB", 10), // object and library
new NTiProgramParameter("*ALL", 10), // object type
new NTiProgramParameter("", 16) // error structure
};
conn.CallProgram("QSYS", "QUSLOBJ", parameters); The conclusion becomes uncomfortable for the market: every administration function reachable from a green screen is just as reachable from .NET, without exception and without an intermediary. Rebuilding an operations console, a profile manager or a multi-partition administration portal, with the look and the rules you choose, is now a matter of scheduling rather than feasibility. The question is no longer whether the system will allow it, it has allowed it since 1988. It is whether you have an access direct enough to address it, and someone to write the calls. Both answers have just arrived at the same time.
An inventory of possibilities
What remains is choosing where to start, and the inventory is mildly dizzying. On the interface side, business portals by department, real time dashboards, data entry screens rethought for touch, shop floor kiosks, mobile access. On the operations side, message queues, job and subsystem monitoring, spooled files, backup supervision, the QAUDJRN audit journal, profiles and authorities, alerts pushed to Teams or to the on-call phone.
On the data side, REST or GraphQL APIs over DB2 for i, automated exports, feeding a warehouse, EDI flows, integration with a CRM. On the business side, the customer or supplier portal, the mobile application for the sales team, barcode scanning querying DB2 for i live. On the development side, impact analysis across your sources, automatic documentation of RPG programs, test data generation. And on the AI side, the MCP server that exposes your processes, whose construction we have documented for SQL as well as for calling RPG programs.
Not a line of RPG in any of it, and not a single change to what already exists. These tools are built alongside, in .NET, and consume the IBM i as a service.
Where to start
The starting point fits in a few lines. A connection string, and the partition becomes an ordinary .NET resource.
using Aumerial.Data.Nti;
var conn = new NTiConnection("server=IBM;user=USER;password=PWD");
conn.Open();
conn.ExecuteClCommand("ADDLIBLE PAYROLL2025"); // CL command
conn.CallProgram("PAYLIB", "PAYLIST"); // existing RPG programFor data, DB2 for i behaves like any relational database, and the Entity Framework Core extension lets you think in LINQ rather than in SQL.
builder.Services.AddDbContextFactory(options =>
options.UseNTi(builder.Configuration.GetConnectionString("IbmI")));
var late = await db.Orders
.Where(o => o.Status == "IN_PROGRESS" && o.DeliveryDate < DateTime.Today)
.OrderBy(o => o.DeliveryDate)
.ToListAsync(); Then comes a step that is easily neglected and yet decides the quality of the result: giving the assistant context. Left to itself it produces approximate code, briefed on the ground it becomes remarkably accurate. The provider supplies part of that: since V5, NTi ships with a context file that already covers the classic pitfalls such as CCSID or the scope of QTEMP.
The rest is yours to add: the DB2 schema of the libraries concerned, easy to extract with a few system queries, your naming conventions and the mapping between short DDS names and long SQL names, an inexhaustible source of errors, two or three code examples already validated in your shop. Then proceed function by function, each one tested against a real development partition before moving on to the next.
Finally, verify, seriously. Test against real data rather than against mock-ups written by the same assistant, which mostly validate its own assumptions. Check the authorities of the profile in use, which should carry the rights it needs and nothing more. And watch the rounding: zoned, packed and DB2 decimals do not behave like a .NET decimal in every operation, and the discrepancy is rarely discovered at a convenient moment.
Generating is not validating
This article would be dishonest if it stopped on that note.
The assistant does not have your business knowledge and never will. It will write a flawless order entry screen; it will not guess that the discount does not apply to part numbers starting with 9, nor why that rule exists. Someone therefore has to know it and be able to state it, which is not always a given.
Nor will it convert your RPG on its own, and this is the point on which we urge the firmest caution. Generating C# from RPG is something a machine can do. Validating the result is not. A program from 1993 wraps up native record level access with cursor semantics, validity checking, indicators, packed decimal rounding and MONMSG statements that, over time, have ended up constituting the business rule itself. A payroll program converted to 97 percent is more dangerous than one not converted at all, for the very simple reason that nobody can say which of the remaining 3 percent is wrong. The right way to go about it is to capture real production inputs and outputs in order to derive a test harness from them, then convert under that safety net: an operation that takes time, not a single click.
Our conviction, after several projects of this kind, comes down to an observation with little poetry to it: AI brings a considerable gain on construction and almost none on specification and validation. The bottleneck does not disappear, it moves: yesterday we were short of time to write the code, tomorrow we will be short of time to check it. That is already a great deal.
The temptation to leave it all behind
It would be tempting to conclude that if everything can be rebuilt, then everything can be left behind. That would be drawing the wrong lesson from good news.
What people hold against IBM i is almost never IBM i itself. It is the green screen, the lack of mobility, the difficulty of integration, the ergonomics of another century. The surface, in short. The engine, with its transactional integrity, its object level security, its journaling and thirty years of running without a major incident, is exactly what nobody wants to rewrite and what no rebuild restores identically. Anyone who has lived through an ERP migration knows what this is about.
Building your tools in .NET around the IBM i means treating the surface without touching the engine, and it brings freedom of movement along the way. Your data access logic is in C#, your queries in LINQ, your applications in containers. The day an infrastructure decision has to be made, it becomes a technical choice again rather than a hostage situation. Most of our customers will never exercise that option and pay for it gladly, because it changes the nature of the conversation with their executive management. That is the logic of our approach to modernization in short iterations, where the IBM i remains the system of record while new functions are built in .NET and deployed in containers.
Everything ends up coming back to the provider, and we take responsibility for saying so plainly, since it is our business. For twenty years, accessing an IBM i was a matter of constraint: you took what existed, with its driver to install, its prerequisites on the partition and its chronic incompatibility with recent versions of .NET. The provider was an infrastructure detail you put up with at the start and regretted in use. It has become the point of passage: fully managed, installable with a single command, able to address DB2 for i, RPG programs, CL commands and system APIs through the same door.
What limits an IBM i project today is no longer the machine, nor the technology, nor even the skills available. It is the path you take to talk to it.
