Some of the best enhancements to IBM i have been in the database. Whether it's the QSYS2.QCMDEXC scalar function (this author's favorite addition), the QSYS2.HTTP_X functions that replaced the older SysTools functions built on Java, or the steady stream of functionality released to take the admin work off your developers' plates, IBM i keeps getting better. Most shops just aren't aware of how much has changed.
A lot of teams are still relying on older workarounds, hand rolled FTP scripts, custom parsers, external middleware, for problems that Db2 for i now solves natively. Here's what some of that newer functionality actually solves, and why it matters.
Calling an API without a middleware tier
Shipping rates from UPS or FedEx used to mean standing up a middleware layer or writing a socket program to reach an external API. Now QSYS2.HTTP_GET and QSYS2.HTTP_POST let you call a REST API directly from SQL. No Java stack, no separate server to patch, no extra service to keep running.
The business value here isn't about newer syntax. Every layer between your database and an external API is one more thing that can fail, one more thing to secure, and one more thing someone has to maintain. Fewer moving parts means fewer points of failure and lower long-term maintenance cost.
JSON without a custom parser
Most modern APIs communicate in JSON, and for years RPG shops handled that by writing and maintaining their own parsers. Db2 for i now includes JSON_TABLE and native JSON generation directly in SQL. You can turn a JSON response into rows and columns, or turn a table into a JSON payload, without writing custom parsing logic.
The business doesn't care what format a vendor's API uses. It cares that the transaction completes correctly. Time spent maintaining a homemade JSON parser is time not spent on the business problem the application exists to solve.
Running system commands without leaving SQL
QSYS2.QCMDEXC lets a program submit a job, check a message queue, or run a CL command directly from SQL. Before this, that meant writing a separate CL wrapper program just to bridge the gap. Now developers can stay in one language and one context instead of switching back and forth between SQL and CL for routine tasks.
This matters because every context switch, from developer to system operator and back, costs time and focus. Reducing that switching lets developers spend more time on the logic the business actually needs.
Closing the admin knowledge gap with a skill the developer already has
In a lot of IBM i shops, there isn't a dedicated systems administrator. There's a developer who can write CL, call APIs, and get a program to do whatever it needs to do. What they don't necessarily have is years of admin experience: which fields in a job log actually matter, what a lock on an object usually means, which system values are worth watching, whether the PTF levels are current. That's not a skill gap, it's a knowledge gap, and it's a different thing.
The system APIs that expose this information have never made that gap easy to close. They're powerful, but they're also dense: return structures defined by byte offset, formats that vary by API, documentation spread across manuals that assume you already know what you're looking for. A developer who is perfectly capable of calling an API still has to know which API to call and how to interpret what comes back, and that's admin knowledge, not programming skill.
Db2 for i has turned a lot of that same information into plain SQL. QSYS2.ACTIVE_JOB_INFO returns job status as a table with named columns instead of a retrieve API's return structure. QSYS2.OBJECT_LOCK_INFO names the job holding a lock and the type of lock, in a result set you can filter with a WHERE clause. QSYS2.PTF_INFO and QSYS2.GROUP_PTF_INFO lay out patch levels as rows you can query and compare. QSYS2.SYSTEM_VALUE_INFO lists every system value with a description, not a code you have to look up.
The developer isn't learning a new tool to get at this. SQL is usually the skill they're already strongest in, ahead of CL and ahead of the API layer. These views hand them the same information the API would, described in language instead of encoded in structure, and let them use the tool they already reach for first to answer the admin questions they used to have to escalate or guess at.
The business impact is the same either way: a shop that depends on one person covering both roles is exposed whenever that person is out, new, or just hasn't run into a particular problem before. Closing the knowledge gap with SQL instead of requiring years of admin experience means that person gets competent on the admin side faster, and the business stops depending on one person having quietly built up knowledge nobody else in the building has.
Security enforced at the data layer
Row and Column Access Control lets the database enforce who can see what, rather than relying on every program to check it correctly and consistently. If security logic has ever been duplicated across dozens of programs, a single missed check is all it takes to create an exposure. Defining the rule once, at the database, removes that risk.
What this means for developers
The functionality is already there, already supported, and already documented. Modernizing an application doesn't always require a rewrite. Sometimes it means reviewing the SQL Services documentation and finding that a workaround your team has maintained for years already has a native replacement built into QSYS2.
None of this happens by accident. Credit belongs to the Db2 for i team, who keep shipping this functionality Technical Refresh to Technical Refresh, largely without the fanfare it deserves. If you want to see more of it in action, IBM maintains a solid collection of tutorials, demos, and SQL examples here: IBM i tutorials, demos and SQL examples.