Learn how to create, compile, bind, and deploy service programs.

Editor's note: This article is excerpted from Programming in ILE RPG, Fifth Edition (MC Press, 2015), chapter 15, "Building and Using Service Programs."

Chapter 14 introduced the bind-by-copy model for creating an ILE program. Under this technique, a program includes a main procedure and optional subprocedures; all code for the program is physically copied into the program during the binding process. The resulting program (*Pgm object) is a single entry-point program. The entry module contains the main procedure, which is the first user-written code that is executed when the program is called. When many different programs use the same subprocedure, then many redundant copies of the subprocedure exist. If it is necessary to change the subprocedure, you must copy the new code into all those different programs, perhaps by using the UPDPGM CL command many times. Unless your organization has excellent documentation disciplines or change management tools, determining which programs are using any one subprocedure can be challenging.

To provide an alternative to the bind-by-copy single entry-point program, ILE introduces a different kind of program, the service program (*Srvpgm object). A service program is a container for subprocedures—a code toolbox that many programs can use without the binder having to physically copy the subprocedure code into each program. This program creation model is called bind-by-reference.

A service program is not a standalone executable object; it does not have a main procedure. Instead, any subprocedure in a service program can be an entry point into the service program. Thus, a service program is said to be a multiple entry-point program. A single entry-point ILE program—or another service program—can invoke any exported procedure in the service program. But, in the service program, only one copy of the actual subprocedure code exists, which many other programs (clients) share. Service programs combine some of the performance advantages of bind-by-copy static binding with the modularity and flexibility benefits of the dynamic program call.

15.3. Compiling and Binding Service Programs

Procedures that reside in a service program have no unique coding requirements. You code the procedures in a service program in Nomain modules. The procedure code uses the same syntax that we've already discussed. Although there is no main procedure, the source can still have a global declarations section. Items you declare in the global section, before any subprocedures, will be available to the procedures within the module. This section includes a prototype for each procedure, and items you declare within a procedure will be local to that procedure. After entering the source code for the module, you compile it normally by using the CRTRPGMOD command. The end result of the compile process is a *Module object.

Typically, procedures in a service program's Nomain module use the Export keyword to ensure that they are available to client programs. If, however, you want to hide a procedure in a service program so that only other procedures in the same module object can invoke it, omit the Export keyword.

As you might expect, you must next bind the appropriate module objects to use them. Just as with single entry-point programs, you can bind service programs from a single module or from multiple modules, and you can include modules written in different languages. Recall that the CRTPGM CL command performs the binding step for a single entry-point program. The CRTSRVPGM (Create Service Program) command performs the same function for a multiple entry-point service program. Figure 15.1 illustrates the prompted CRTSRVPGM command.

Figure 15.1: CRTSRVPGM (Create Service Program) command

The CRTSRVPGM command looks much like the CRTPGM command, and it serves much the same purpose, except that it creates a service program. As with the CRTPGM command, the service program binding process requires a list of modules to copy into the *Srvpgm object. Notice, though, that CRTSRVPGM specifies no parameter to designate an entry module. Because a service program is a multiple entry-point program, there is no entry module.

When you create a service program, its procedures might refer to other procedures that reside in other service programs. The CRTSRVPGM binder can list those service programs (in the BNDSRVPGM parameter, under Advanced Parameters), which are then bound by reference to the service program you are creating. All the exported procedures from those service programs are available to your service program as well. We'll discuss binding by reference in more detail shortly.

Also notice that the CRTSRVPGM command, like the CRTPGM command, supports the use of binding directories. Recall from Chapter 13 that a binding directory—a list of reusable modules—allows the binder to find necessary modules that you may not have explicitly listed with the binder command. In addition to module entries, a binding directory can store the names of service programs that you intend to reuse among many different programs. When the binder finds the required procedure in a module entry, it binds the module by copy. When it finds the necessary procedure in a service program entry, it binds the service program (and all its procedures) by reference. Once the binder finds all the procedures it needs, the end result of a successful binding step is a *Srvpgm object.

15.4. Deploying Service Programs in an Application

A single entry-point program—or another service program—can invoke any procedure in a service program. But the calling program does not call the service program itself. Because a service program lacks a main procedure, you cannot call it. Instead, the caller invokes an individual procedure in a service program by using the same syntax that it would use if the procedure were bound to it by copy:

Callp Updcust(Company:Custnbr);

or

Metrictemp = Celsius(Englishtemp);

or

If Celsius(Englishtemp) > 100;

…

Endif;

Recall that when you bind a module to a program, the binder physically copies the executable code from the module into the program—hence, the term bind-by-copy. When you bind a service program to an ILE program or to another service program, the binder does not physically copy the code to the client. Instead, the binder makes a reference associating the client with the service program and each of the procedures in it (i.e., bind-by-reference). You can think of the program as jotting a note to itself, a reminder that when it's time to load itself at runtime, it must also load any service programs that have been bound to it by reference. After the client program and any of its associated service programs have been loaded, all the procedures work together as a unit, regardless of whether they were bound by copy or by reference. If the client program cannot find all the service programs bound to it, or if a bound service program no longer exports a needed procedure, the program activation fails.

Regardless of how many clients use the procedures in a service program, only one copy of the executable code exists in the service program. When many programs use a procedure, bind-by-reference avoids the redundancy of bind-by-copy, and it can eliminate the need to update many programs when you must correct or enhance a procedure.

If the way you invoke a procedure in a module and the way you invoke it in a service program are the same, how will your program know which technique to use? The answer lies in the way that you bind the procedure to the calling program. When you use the CRTPGM command to bind a single entry-point program or the CRTSRVPGM command to bind a service program, you choose between either bind-by-copy or bind-by-reference. These commands have three parameters in common that control the binding technique:

• MODULE
• BNDSRVPGM
• BNDDIR

You have several components to consider when creating a single entry-point program or a service program. Both the CRTPGM command and the CRTSRVPGM command bind these components in order. First, all the *Module objects listed in the MODULE parameter are bound by copy. Next, all the *Srvpgm objects listed in the BNDSRVPGM parameter are bound by reference. Finally, for any unresolved exports, the binder searches entries in the binding directories listed in the BNDDIR parameter. If it finds a required procedure in a module entry, it binds that *Module by copy. The binding directory can also list service programs as well as modules (Figure 15.2). If the binder, either CRTPGM or CRTSRVPGM, finds a needed procedure in a service program entry, it binds that *Srvpgm by reference. The binder ignores all unnecessary binding directory entries to complete the binding process.

Figure 15.2: Binding directory entries

When the binding process uses a service program by reference, all the exported procedures in that service program are available to the bound program (or service program), whether or not the bound program uses all of them. You should organize service programs efficiently to avoid unnecessarily activating an excess of procedures that the client program will not use. The procedures in a single service program should be closely related to each other, a concept known as cohesion. Usually, when you activate a service program, most of the procedures in it should be used.

When you first activate an ILE program or service program, by default, all the service programs bound by reference are also activated. Activation allocates and initializes the storage needed to execute the program or service program. You can choose to defer activation of a particular service program until the caller invokes one of the exported procedures in the service program (i.e., until it truly uses the service program). When you specify a service program in the binder's BNDSRVPGM parameter, or you list it in a binding directory, indicate *DEFER instead of *IMMED activation (Figures 15.1 and 15.2). Deferred activation can offer a small performance improvement if the program binds many service programs but uses some of them only infrequently in actual practice.

The DSPPGM (Display Program) CL command lists the modules and service programs that make up a program if you specify the parameter value DETAIL(*MODULE *SRVPGM). Figures 15.3 and 15.4 illustrate the DSPPGM output. Similarly, the DSPSRVPGM (Display Service Program) CL command shows the modules and service programs that a service program uses. RDi's Remote Systems Explorer also offers an application diagram to help visualize the program or service program construction (Figure 15.5).

Figure 15.3: DSPPGM DETAIL(*MODULE)

Figure 15.4: DSPPGM DETAIL(*SRVPGM)

Figure 15.5: RDi application diagrams