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!
LATEST COMMENTS
MC Press Online