Let’s talk PSM. Can you distinguish your SPs from your UDFs? You’re now totally lost, I imagine. Don’t worry, this TechTip explains all this (and more) SQL jargon.

PSM stands for Persistent Storage Module. In short, it’s the language used to write “SQL programs.” I’ll delve into PSM with much greater detail later in this series, but for now, let’s just focus on what forms these SQL programs, or SQL routines as they are more commonly called, can take. There are three ways to create them: as stored procedures (SPs), user-defined functions (UDFs), and triggers (sorry, there’s no abbreviation for triggers). You’re probably wondering how to distinguish them and when to use which. Mainly, it has to do with the way these routines are called:

• 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.

In this and the next articles, I’ll focus on SPs and how they can be used to encapsulate RPG procedures or programs.

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.

I explained why you should do it in a previous article of this series. As mentioned, you can chose from three “flavors”: stored procedures, user-defined functions. and triggers. Let’s forget triggers for now and focus for a minute on the last word of each of the other two terms: procedures and functions. If you know a bit about ILE or even just programming in general, you already know how to distinguish between procedures and functions, and you should have a rough idea of which to use when.

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.

I know that you’re probably eager to get started, but that’ll have to wait for the next TechTip. There’s a lot to explain, and it wouldn’t be possible to cover it in the necessary depth this time around.