Previous TechTips described procedures and functions. Now it's time to talk a bit about parameters. Read on to find out more!

We talked about procedures and functions, describing them as something similar to subroutines with parameters. So let's talk about those parameters: how they work, how to best use them, and other interesting facts.

There are multiple ways to pass information from one program to another program. You can exploit the LDA, use a temporary file, or pass parameters, just to name a few. Some methods are easier to implement and maintain than others because they're more explicit and "debuggable." Passing parameters is, in my opinion, the best solution in the vast majority of situations: parameters are easy to use, they're efficient (because only the memory address is passed to the called program, the amount of data being passed is minimal, thus making the data access operation more efficient), and you can access their contents in a straightforward manner when you're debugging.

However, there are some pitfalls. Have you ever had that weird situation where something is changing a variable but you can't figure out what it is? Then, after some frustrating (and sometimes infuriating) investigation, you discover that the value of the variable got changed by a program call that used that variable as a parameter. Been there? I have. This happens because, by default, parameters are passed by reference. This means that you actually pass the reference (or memory pointer) of the parameter to the program you're calling. As that program runs, it may change the contents of the parameter and, since it's using the actual memory slot that the variable is stored in, return a wrong value to the calling program. Calling a program in OPM or ILE will always pass the parameter by reference, but when you're calling an ILE procedure or function, you can specify how the parameters should be handled: by reference (the default by omission) or by value. This second option means that the value of the variable, not the memory pointer, is passed to the procedure, so there's no risk of the original variable value being changed. You might say, "Wow! That seems great, but how do I do it?" Well, I've shown it already a couple of times in other TechTips of this series. Let's use the previous TechTip's USD_To_Eur function as an example:

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

*   Convert USD to Eur at the current exchange rate    

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

P USD_to_Eur     B                   EXPORT                      

D                 PI           11 2                          

D P_USD_Amt                   11 2 Value                          

Notice the Value keyword that's in the P_USD_Amt line. That keyword means that the USD_to_Eur function may use the parameter freely, because when the function call ends, the value of the variable P_USD_Amt in the calling program will remain unchanged. This is also a simple way to separate the input and output parameters of a procedure. I usually use the Value keyword in the input parameters, not only because their value remains unchanged but also because it makes the code more readable: with just a quick look at the procedure interface, I can easily determine which are the input and output parameters of the procedure.

However, as with everything in life, there are exceptions: Sometimes, you'll need to perform mostly the same operations but with slight differences. Imagine, for instance, that you need to convert USD to Eur, as in the previous TechTip example, but you'd also like to specify a date in order to get that day's conversion rate instead of the latest available. It seems simple enough: Just add a reference date parameter to the USD_to_Eur function, right? Well, then you'd have to check whether something was passed, whether that something is indeed a valid date, and whether it's supposed to be used. This last part can be tricky: Zero is not a valid date, but it might be a way to "tell" the function to use the latest available exchange rate. It's obviously possible (and this is a simplistic example), but there's a simpler way: If you don't want to specify a reference date, just don't! OK, now the call to the function causes a compilation error because you didn't specify enough parameters. There's a solution for this scenario: Use the OPTIONS(*NOPASS) keyword. The new procedure interface would look like this:

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

*   Convert USD to Eur at the current exchange rate    

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

P USD_to_Eur     B                   EXPORT          

D                 PI           11 2                  

D P_USD_Amt                   11 2 Value              

D P_Ref_Date                   8 0 OPTIONS(*NOPASS)

Then the function's code would have to determine how many parameters were passed, in order to execute the appropriate code. That would be achieved with the %Parms BIF. %Parms returns the number of parameters that were passed. Here's how to use it:

C                  If       %Parms = 2

* The reference date was passed,

* So get the exchange rate for that date

*                (some code here)

C                   Else

* Only the USD amount parameter was passed,

* So get the latest exchange rate available

*                (some other code here)

C                   EndIf

* Now that the exchange rate is set, do the conversion

*                 (some more code here)

You have to follow a couple of rules when using the *NOPASS option:

• Adapt your code to cope with the number of parameters that were passed, using the %Parms BIF. If you try to use a parameter that was not passed, you'll get a "pointer not set" error and the program will crash.
• All the parameters specified after the first parameter with *NOPASS also have to have that keyword. This requirement can be annoying when you have multiple parameters and just want to pass the last one, but there's a solution for it! I'll discuss it in the next TechTip.

That's all for now! The next TechTip will continue to discuss parameters, picking up where this one left off.

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