Last Updated on 2 November 2025 by Roberto De Pedrini
Hello everyone,
I’d like to highlight another excellent contribution by Massimo Duca, part of his ongoing IBM i & SQL Tips series.
In this article, Massimo demonstrates how to use the SQL table function QSYS2.STACK_INFO to inspect and identify the programs present in the call stack of an IBM i job.
🔗 IBM i & SQL Tips #010 – Locate programs in the call stack – Massimo Duca
🧠 What STACK_INFO Does
The QSYS2.STACK_INFO table function returns detailed information about the levels in the job’s call stack — in other words, the sequence of programs and procedures currently active in a given job.
With a simple SQL query, you can quickly determine who called whom without having to write RPG code or use lower-level system APIs.
Massimo clearly explains how to filter the results, interpret the key columns (program, library, entry type, call level), and how this information can be used for debugging, logging, or even conditional logic based on the caller.
A clear and practical example — very much in his signature style.
⚙️ What about performance?
The use of STACK_INFO naturally raises a performance question: how does it compare with the traditional Retrieve Call Stack API (QWVRCSTK)?
While the API provides the highest degree of control and efficiency, it requires explicit coding, buffer management, data-structure handling, and parsing.
By contrast, STACK_INFO allows you to achieve the same result in just a few lines of SQL — far easier to use and to integrate into modern workflows.
In environments where call-stack inspection isn’t continuous or performance-critical, this simplicity easily outweighs the minor overhead of using SQL instead of a native API.
💡 A broader reflection
Massimo’s article is a great example of how the IBM i Services introduced in recent releases are transforming system programming: they make it possible to access information that once required complex APIs like QUSRJOBI, QWCRSVAL, or QWVRCSTK — directly through SQL.
These services don’t always replace the original APIs — which remain faster and more granular — but they significantly simplify the developer’s life, integrating seamlessly with modern tools such as Access Client Solutions, VS Code, and SQL-based environments.
In this sense, articles like Massimo’s help the IBM i community appreciate the best of both worlds: the robustness and depth of IBM i, combined with the accessibility and flexibility of SQL.
📘 Read Massimo Duca’s full post here:
👉 IBM i & SQL Tips #010 – Locate programs in the call stack


