Expose existing IBM i business logic through Db2 for i stored procedures. This article explains how procedures differ from functions and triggers, then walks through registering an RPG procedure with CREATE PROCEDURE.

By Rafael Victória-Pereira

You can make an existing ILE RPG program or exported procedure callable through SQL without rewriting its business logic. First, you need to decide whether a stored procedure fits the job; then you need to define an SQL interface whose parameters match the RPG entry point. Let’s work through both decisions.

SQL/PSM stands for SQL Persistent Stored Modules, the procedural SQL language used to write SQL routines. Here, I’ll focus on the forms routines can take: stored procedures (SPs), user-defined functions (UDFs), and triggers. How do you distinguish them and decide which to use? The main difference is how they are invoked:

SPs are called from other programs (for instance, other SPs or external programs, such as a client/server application invoking database code, using the CALL statement). You can’t call a SP directly from a “regular” SQL statement, such as a SELECT, INSERT, or UPDATE However, you can call SPs from PSM code, using the aforementioned CALL statement. SPs are mostly used to return data sets, in the form of cursors, but they can return data as output parameters.

UDFs are almost the exact opposite of SPs: You can call them only from “regular” SQL statements. UDFs return a value themselves (if you remember the canonical definition of procedure versus function, you’ll know what I mean) and are typically used to perform complex calculations or check complicated business rules.

Triggers are not like SPs and UDFs; you can’t call them directly. They are activated by database events, such as a record insertion, update, or delete. They don’t return anything, and they have a very special set of input parameters, as you’ll see in a later article of this series.

For the rest of this article, I’ll focus on stored procedures and how they can expose RPG procedures or programs through SQL.

First of all, what are SPs? Their name hints that they are SQL “programs” of some sort. That’s only partially true. SPs are indeed program-like things that can be written in SQL’s procedural language. Originally, only the C language was available to write external SPs, but (for a while now) it’s possible to write them in several other languages, including RPG.

Why use an SP here? Consider the distinction between a procedure and a function. If you know ILE or programming in general, you already have a sense of which one fits a particular task.

SPs are great when you want to trigger an action, like an order-entry process, and have the output, an order number in this case, passed back to the caller as a parameter. This means that SPs are a good choice for programs written in other languages (other platforms, servers…the world outside your IBM i) to trigger complex actions in your core applications in a controlled manner. SPs are not appropriate for use on a SELECT statement or any other kind of data manipulation language (DML) statement because they require an explicit call, like standard programs do (don’t worry, I’ll get to that later).

You’re probably thinking that you can also use triggers to set in motion a complex action, and that’s true. The problem is that triggers can’t take parameters or return values. They simply react to a change in a table that matches certain conditions. For some situations, this is enough. However, if you want to use your existing business logic RPG programs to open your application to the “outside world,” triggers are not the way to go. SPs are simply to create and maintain; they usually don’t require rewriting existing RPG code, and their use is consistent with the SQL standards, which means that even a programmer who doesn’t have the faintest idea of an IBM i is able to use them.

With that distinction in place, let’s turn to the IBM i implementation. An existing RPG program or exported procedure can serve as the external implementation of an SQL stored procedure when its interface is compatible with the SQL definition. The next example registers an item-availability procedure so an SQL caller can supply an item and quantity and receive an availability date.

Converting an Existing RPG Procedure into an SQL Stored Procedure

Let’s take a simple item availability procedure as an example. This procedure takes an item ID and a quantity as input parameters and returns the expected availability date as an output parameter. Note that this is just a procedure, a small modular part of the much bigger order entry process, but you can also declare a full-blown program as an SP—it’s just a matter of more or less parameters, from SQL’s point of view.

Registering a procedure as an SP is simple. SQL provides the CREATE PROCEDURE instruction for that. Let’s start by looking at the item availability’s procedure interface:

*----------------------------------------------------------------------*

*   Item availability (returns the expected availability date for     *

*                      given item id and quantity)                     *

*----------------------------------------------------------------------*

P Rtv_ItemAvail   B                   Export                              

D Rtv_ItemAvail   PI                                                    

* Input parameters                                                      

D P_ItemID                     15A 0 VALUE                              

D P_ItemQty                     9P 2 VALUE                              

* Output parameters                                                      

D P_AvailDate                   D                        

This is a typical procedure interface, and it should be self-explanatory. Sorry for the fixed-format code, but that’s actually irrelevant for this explanation. Actually, it serves to show that existing, “unmodernized” code can be used in this process. Now let’s write the corresponding CREATE PROCEDURE statement:

CREATE PROCEDURE RetrieveItemAvailability

(IN ItemID CHAR(15), IN ItemQTY DEC(9,2),

   OUT AvailDate DATE)

EXTERNAL NAME 'MyLib/BRItm(Rtv_ItemAvail)'

LANGUAGE RPGLE

PARAMETER STYLE General

Let’s analyze this line by line:

The first line contains the necessary SQL instruction and the SQL name of the SP, which can, as it is in this case, be different from the RPG name.

The second and third lines define the SP’s parameters, using the reserved words IN and OUT to clearly identify parameters as input or output. Just a couple of notes regarding the parameters: there’s a third option, INOUT, that declares the parameter as both input and output, which is RPG’s default for parameters. Unless you use the VALUE or CONST keywords, all RPG parameters are both input and output parameters. The SP parameter names don’t have to match the RPG procedure parameter names; they are only placeholders for the parameters and their data types and lengths.

The next line provides the necessary link between the SQL name and the RPG name for the procedure, using the EXTERNAL NAME keyword, followed by the structure <library name>/<service program name>(<RPG procedure name>). If I wanted to use a *PGM object as an SP, the last part (<RPG procedure name>) would not be necessary. In other words, if my SP is going to be linked to a program called ITMAVB, this line would become this:

EXTERNAL NAME MyLib/ITMAVB

The fifth line indicates the language in which the procedure is written. If the object already exists, SQL can figure out the language on its own; however, for documentation and clarity purposes, it’s a good practice to include this line here. Finally, the PARAMETER STYLE General line indicates which parameter “working model” will be used. Note that even though GENERAL is the most used and will probably be enough for most situations, other options exist, such as SQL, DB2GENERAL, GENERAL WITH NULLS, and JAVA. I won’t explain them here, so after you get some practice with SPs and UDFs, please refer to the DB2 for i SQL Reference manual for details.

This is the simplest possible CREATE PROCEDURE statement I can issue for the Rtv_ItemAvail procedure. There are two more lines that I didn’t include here because SQL provides default values for them, allowing you to bypass them. The DETERMINISTIC or NOT DETERMINISTIC specification determines whether the procedure returns the same results each time the SP is called with the same IN and INOUT arguments. The default is NOT DETERMINISTIC, which means the SP may not return the same result each time the procedure is called with the same IN and INOUT arguments, even when the referenced data in the database has not changed.

DETERMINISTIC means that the SP always returns the same results each time the procedure is called with the same IN and INOUT arguments, assuming the referenced data in the database hasn’t changed. In other words, it means SQL doesn’t have to call the procedure repeatedly if the parameters’ values don’t change, because it can “remember” the last answer and not call your procedure, thus improving performance. Keep in mind that the default is NOT DETERMINISTIC, so in most cases, there’s a performance gain in specifying DETERMINISTIC in the CREATE PROCEDURE statement.

The other specification is related to RPG’s code itself. It specifies the classification of SQL statements that this procedure, or any code called by it, can execute. The database manager verifies that the SQL statements issued by the procedure and all code it calls are consistent with this specification. The default is MODIFIES SQL DATA, but there are other options:

NO SQL—The procedure (and any other code it calls) doesn’t use any SQL whatsoever. If it tries to use SQL, an error will occur.

CONTAINS SQL—Only a few SQL instructions, like COMMIT, ROLLBACK, and SET, are allowed. Note that the SQL statements used in the procedure can’t include DML instructions.

READS SQL DATA—Reading data using SELECT or FETCH statements is allowed, but updates via SQL are not.

MODIFIES SQL DATA—All SQL statements that are supported in procedures are allowed, including DML and DDL instructions.

After issuing this SQL statement, the RPG procedure is linked to the database, which means that every time you recompile the module where it resides, you must also recreate the SP. How do you do that? You need to issue a DROP PROCEDURE statement, like this one:

DROP PROCEDURE RetrieveItemAvailability

This is followed by a new CREATE PROCEDURE, similar to the one you used before, unless the procedure’s parameters have changed. In that case, you need to adapt the SP’s parameters to match the RPG procedure’s parameters’ type and length.

It’s a good practice to save your CREATE PROCEDURE statements, which can get pretty huge when the number of parameters grows, in a separate source member. I personally like to use QSQLSRC and execute them with the RUNSQLSTM CL command, but I’ve seen folks save them in the IFS and execute them in the i Navigator Run SQL Scripts tool.

That gives an existing RPG procedure an SQL-callable interface. Keep the CREATE PROCEDURE definition with the application source and verify the parameter mapping whenever the RPG interface changes. User-defined functions offer another way to reuse RPG code when the caller needs a value within an SQL expression.

Rafael Victória-Pereira has more than 20 years of IBM i experience as a programmer, analyst, and manager. Over that period, he has been an active voice in the IBM i community, encouraging and helping programmers transition to ILE and free-format RPG. Rafael has written more than 100 technical articles about topics ranging from interfaces (the topic for his first book, Flexible Input, Dazzling Output with IBM i) to modern RPG and SQL in his popular RPG Academy and SQL 101 series on mcpressonline.com and in his books Evolve Your RPG Coding and SQL for IBM i: A Database Modernization Guide. Rafael writes in an easy-to-read, practical style that is highly popular with his audience of IBM technology professionals.

Rafael is the Deputy IT Director - Infrastructures and Services at the Luis Simões Group in Portugal. His areas of expertise include programming in the IBM i native languages (RPG, CL, and DB2 SQL) and in "modern" programming languages, such as Java, C#, and Python, as well as project management and consultancy.

---

MC Press books written by Rafael Victória-Pereira available now on the MC Press Bookstore.

		Evolve Your RPG Coding: Move from OPM to ILE...and Beyond Transition to modern RPG programming with this step-by-step guide through ILE and free-format RPG, SQL, and modernization techniques. List Price $79.95 Now On Sale
		Flexible Input, Dazzling Output with IBM i Uncover easier, more flexible ways to get data into your system, plus some methods for exporting and presenting the vital business data it contains. List Price $79.95 Now On Sale
		SQL for IBM i: A Database Modernization Guide Learn how to use SQL’s capabilities to modernize and enhance your IBM i database. List Price $79.95 Now On Sale