The previous TechTips were about procedures, so it's now time to move to the next stop of our OPM-to-ILE journey: the functions. Read on to find out more!

This TechTip will cover the basics of functions and provide a simple example. Functions can make your work much easier by increasing your code's readability, flexibility, and modularity. You've probably already used a built-in function (BIF) or two, such as %EOF or %Found. These are great tools that simplify our work, increase code readability, and allow us to write shorter pieces of more flexible code.

BIFs are great, but do you know you can build your own functions? Just think about the possibilities! It's quite an easy task, actually, because functions are very similar to the procedures discussed on the previous TechTips. The main difference is that a function returns some sort of value. Not in a parameter, like an OPM program or an ILE procedure would do, but in the call itself, like a BIF does.

If you're a regular reader of this series, you should be familiar with the inventory scenario I've been using since the first TechTip. If you're not, I really recommend that you start there and make your way back to this one! The "Check if item exists in inventory" procedure, discussed in the previous TechTip, could be easily transformed into a function, thus providing a great example to start with. The idea behind this procedure is that several programs need to know if an item is in stock in order to do something with it. From the procedure's point of view, it really doesn't matter what; its objective is simply checking if an item exists in the inventory. For the other programs, however, it's not that simple: they need to call the procedure, check its output parameters, and then perform whatever operation they need to perform. If we transform this procedure into a function that returns *On or *Off, it can be used directly in an IF statement. Something like this:

IF Check_Item_Exists_In_Inventory(Item_ID: Item_Quantity : Item_Unit_Price) = *On Then (do something)

Now let's turn this into RPG: procedure and function names should be short but understandable, as I explained in the fourth TechTip of the series, so a more suitable name for our function would be ChkItmInInv (notice the capitalization; each abbreviated word starts with a capital letter). This makes it easier to read and understand, even though there are some letters missing. This function takes the Item ID as a parameter, so it should be named P_ItmID. It returns the Item Quantity and Unit Price, so let's shorten their names to P_ItmQty and P_ItmUnPrc. Again, shorter but understandable. The code would remain basically the same: read the inventory master file using the Item ID parameter as key and return the quantity and unit price found in the respective output parameters—just like an OPM program would do. The big difference is that we can now return an indicator (or any other kind of value, really) to help the calling program decide if and how to use the output parameters without having to check them! Let's say we'd return *On if the item was found and *Off otherwise. Our function's code would look something like this:

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

*   Check if an Item exists in inventory      

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

P ChkItmInInv     B                   EXPORT                        

D                 PI             N                            

D P_ItmId                       50                                  

D P_ItmQty                     10 0                                

D P_ItmUnPrc                   11 2                              

C*                                                                  

C* The function's code goes here

C*

C* Because this is a function,

C* a RETURN statement is required

C* so we need some logic to determine what to return

C                   If       P_ItmQty > *Zeros    

C                   Return   *On

C                   Else

C                   Return   *Off

C                   EndIf

C*                                          

P ChkItmInInv     E                                

There are a couple differences here, and the first one is very subtle: notice that there's an "N" in the "PI" line? That doesn't exist in a procedure's interface. This definition is what determines that is a function (because it returns something) and, in this particular case, defines that the returned value is of the "N" type—an indicator. Somewhere in the code, usually near the end of it, there's some logic to determine the value to be returned, and the op code RETURN is used to return that value. This detail is what allows us to do this:

C* Check if Item exists in the inventory before update

C                   If       ChkItmInInv(P_ItmID   :

C                                         P_ItmQty :

C                                         P_ItmPrice) = *On

C* The item exists, do something with it

C                   ExSr     Some_SR

C                  EndIf

If you remove the two differences I explained before, ChkItmInInv goes back to being a procedure and you would call it with CallP, just as I explained a couple of TechTips ago. This is a simple (perhaps too simple) example, but it serves the purpose. You can create functions to encapsulate complex financial formulas that you use in several programs, or to hide some business logic in order to increase a program's readability, or a million other things.

Let me finish with some suggestions: there's a lack of string-formatting BIFs, so you could start there, by creating your own functions to:

• Capitalize Every Word In A Sentence
• TURN EVERY WORD INTO UPPERCASE
• or into lowercase
• jsut jblume teh ltteres a bit (just jumble the letters a bit)

It's good practice (and a bit of fun too!).

In the next RPG Academy TechTip, I'll continue to talk about functions, because there's a lot more to be said. Until next time!

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

Also Read

Programming in ILE RPG - Defining Data Structures, Part I

H and F Position-less Specs

Practical RPG: AI and IBM i