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.

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