Reap benefits by using ILE RPG Service Programs

A service program (object type *SRVPGM) is a set of procedures that can be bound into ILE RPG programs. Basically when the service program is referenced any of its procedures might then be called. These callable procedures that are defined to the service program are referred to as exports which can be any ILE module, program, or even other service programs.

Service programs do not have a program entry procedure and therefore are non-callable. When bound the service program code is only referenced by linkages. That is, unlike other bound programs, the service program exports are not directly copied into the compiled program. The benefit of using a service program is easier maintenance, consistent performance, and more efficient processing.

As you know many software packages will have some global APIs. A date manipulation/validation API is a prime example of when a service program, full of date validation and conversion sub procedures, could be used. Other common examples include string manipulation procedures, combining procedures that retrieve or manipulate the run-time environment (adding to the library list for example), message handling, authority checking, XML, data encryption, IFS interface, email, etc.(something like a Java class or windows DLL).

You create modules with CRTRPGMOD which is option 15 in PDM. You can think of these procedures as similar to reusable subroutines, only more flexible. A module can have many procedures which each have Begin and End P specifications which are like tag statements that mark the starting and ending lines of the procedure.

If NOMAIN is entered on a control (H) specification the module can not have a main procedure, has no entry point, and cannot use the RPG cycle. Care must be exercised when mixing modules with a main procedure with NOMAIN modules due to issues with files already opened or closed, locked data areas, calling sub procedures before the main procedure is called, and global data initialization and data integrity issues. The best way to avoid errors is to make all your modules NOMAIN.

CRTRPGMOD module(mylib/mod1) srcfile(mylib/qrpglesrc)
You create a service program, and bind modules to it, with CRTSRVPGM which does not require a source member.

CRTSRVPGM srvpgm(mylib/srvpgm1) module(mod1, mod2, mod3) export(*all)
Referring to the service program can be done one program at a time or, better yet, by using a binding directory. With the binding directory specified in the control specifications any unresolved procedure, sub procedure, program, or service program in that directory can be accessed when compiling and the CRTBNDRPG, CRTPGM, and CRTSRVPGM will not need individual module names specified. To see an IBM binding directory use the following command;


After the binding directory has been created and procedures have been added the calling program can specify the binding directories in the H specs ;

0001.00 H DftActGrp(*No) ActGrp(*caller)
0002.00 H BndDir('BIND1':'BIND2')
Such a program must be created with the CRTBNDRPG command which is PDM option 14.

Note that the DftActGrp is set to *No to take advantage of ILE binding. Think of DftActGrp(*Yes) as more related to OPM programming and DftActGrp more appropriate for ILE.

There are a few issues to consider when using service programs. When the caller references the service program some overhead is incurred. Normally this is offset by performance improvements. It is only an issue if the service program is called from the same program repeatedly. Also, certain changes to service programs can alter the "signature" of the service program which might require rebinding or recompiling some programs. This situation can be avoided by using binding source which may well be the subject of a future article!

Conclusion: Service programs are a powerful addition to your developer toolkit. While initially they may seem complicated, usage of service programs is practical, logical, and efficient. Developers may wish to work with some new applications and create a "global" binding directory, adding a few NOMAIN modules, and creating a new service program that binds these modules. Learn how to call and debug that much first. In other words, get familiar with the concepts before "jumping in with both feet". There is usually no pressing need for retrofitting legacy code using these new techniques. Going forward, taking advantage of ILE development concepts like service programs, modules and procedures, and binding directories is a no-brainer, just do it!