Forums >> Programming >> RPG Programming >>
Our First RPG ILE Module


Our First RPG ILE Module

Our First RPG ILE Module

For our first ILE module I wanted to keep things very simple.  That's because I'd rather you focus HOW it is done vs WHAT it is doing.

With that said, the source for our first module is as follows:

H NOMAIN                                                              
 * Prototypes                                                   *     
D #getSumInt      PR            10i 0                                 
D  Augend                       10i 0 Const                           
D  Addend                       10i 0 Const                           
 * getSumInt - Return the sum of two integers                   *     
P #getSumInt      B                   EXPORT                          
D #getSumInt      PI            10i 0                                 
D  Augend                       10i 0 Const                           
D  Addend                       10i 0 Const                           
  return (Augend + Addend);                                           
P #getSumInt      E            

I called this first source member F.MATH and placed it in the source physical file QMODSRC.

Now, you probably will notice a few things about how I personally do ILE.  Not all of the methods I use are shown here, but a lot of them are:

  • I always name the module source member F.xxxxxx where xxxxxx is the descriptive name.  In this case, we'll play around with procedures that perform "Math" functions.
  • I place the module source in QMODSRC
  • I like to prefix my subprocedure names with the # character.  You don't have to do this, I choose to to make them easier to find in programs.  You'll find in later examples I also prefix the modules with #name_ where "name" is a grouping name.  (ie, #math_getSumInt would be a more descriptive name that I would use in production).  And yes, I do understand the hash tag won't work in all language sets, but this can be swapped for another character.  

These are not the only unique choices I've made over the years.  You'll notice others as we progress, but here's a short list of additional methods I use:

  • I name the /COPY member containing the prototypes P.xxxxxx and place it in the source physical file QCOPYSRC.  In this example we haven't used a /COPY member yet, but soon will.
  • If a service program will be used, I name the binder language F.xxxxxx (the same as the module) and place it in the source physical file QSRVSRC.  This is mainly because the defaults for the Create Service Program (CRTSRVPGM) command use these as defaults.

But, before we get too far ahead of ourselves, let's take a look at the module we're working with.

First, we see the NOMAIN H spec.  All this does is tell the compiler there is no main or entry module.  In other words, we can't just CALL this module, instead we will be calling the subprocedures within.

Next we see the prototype(s) for any subprocedures in the module.  In this case there is only one (so far).  Normally this would be a /COPY directive, but for this example we are all inclusive.

The prototype is used in both the module and and program to describe the function and it's parameters.  It's important to note that the names for the parameters aren't required, and are really "informational only".  But, the data type and size declarations are required as well as any keywords such as CONST, VALUE or OPTIONS.

Next we see the Procedure Beginning (specified by the "B" following the procedure name).  Also, we see an EXPORT keyword.  This is used if we want to export the function to be used by any other applications other than itself.  (There are actually times where you won't want to export a procedure, but we will cover that later).

Next is the Procedure Interface (PI).  This is similar to the prototype and yes, seems redundant.  But, this actually sets up the parameters to be usable in the procedure itself.   In this case the parameter names are required as these names are how you will access the values of the parameters in the actual procedure.

Finally we have the Procedure End (specified by the "E" following the procedure name).

You may have noticed the two parameters to the procedure use the keyword CONST.  This means that the values will be "read only" and cannot be changed within the procedure.  It also means that you can pass the data as a "value" (ie, the number 10 instead of a variable with the value 10).  If the parameters were both input and output, then you would omit this keyword and any change made to the parameter would be passed back to the calling program.  You can also use the VALUE keyword which acts in a similar method as CONST.  There has been much discussion about these keywords so instead of me getting into which is "better", you can decide that for your self after reading all that is available (or just as much as you want) from a internet search.

Now, there's no reason to have a procedure to find the sum of two numbers.  But, hopefully the simplicity of this will allow you to focus on the procedure definition and use itself instead of what the procedure does.

To create this module we would issue the following command:


Next, we will see how to use this module and procedure in a program.

Last edited 04/03/2015 at 06:36:19


Copyright 1983-2017 BVSTools
GreenBoard(v3) Powered by the eRPG SDK, MAILTOOL Plus!, GreenTools for Google Apps, jQuery, jQuery UI, BlockUI, CKEditor and running on the IBM i (AKA AS/400, iSeries, System i).