Service programs let you use your business logic with more flexibility.

If you've never heard of a service program or actually worked with one, there are many fantastic introductory resources out there. We here at MC Press Online have a wide selection of them, including great articles written over the years and excellent books as well. They provide a thorough explanation of the fundamental concepts, and I recommend that you use those resources prior to beginning your journey into service program design. But if you already know the basics of service programs and have maybe even dipped your toe into the architecture of modules, binder source, and UPDSRVPGM, then you might now be asking a simple question: Why would I use a service program?

Not Just a PLIST on Steroids

At the simplest level, service programs contain procedures that you can call using prototypes. Service programs essentially allow you to encapsulate common business logic used by multiple programs into a single entity, which in turn provides future-proofing; change the business rules in one place (the service program) and it takes effect throughout the entire application. To be sure, this can be done in other ways: called programs or even /COPY books (eww!). And when people first begin implementing service programs, one of the things they do is write a procedure for each called program.

To me, the primary benefit of service programs is that they provide multiple interfaces to the same business logic. To appreciate how this behavior allows us to write better code, we have to understand some concepts from the world of object-oriented programming (OOP). In OOP, the ability to call the same business logic different ways is called “polymorphism,” and it's one of the most powerful techniques you can use to future-proof your code, because it allows you to start with a basic implementation and add features as time goes on.

I'm going to avoid delving too deeply into OOP for the time being. If you'd like to familiarize yourself with some of the conceptual framework around polymorphism, you might want to investigate some of the related terms, such as Adapter and Facade. A wealth of information is available online; as one example, I suggest reading Thorben Janssen's article on Stackify as a fantastic overview of the Adapter. Just understand that ILE doesn't directly support OOP, but it does allow us to borrow the concepts.

Let's start with the fundamental difference between calling a program and calling a service program procedure. The first thing to note is that you don't call a service program, you call a procedure in the service program. And since you can have many procedures in the service program, that means a service program has multiple entry points. That's the magic! Let me take a real-world example of this. An old ERP system I work on employs a very old-school way of converting between numeric and alphanumeric values. It uses a /COPY book that defines a subroutine. The calling program loads a bunch of predefined variables with data and then performs an EXSR (execute subroutine) to the appropriate subroutine. When the subroutine returns, the program checks other predefined variables for the results. Since the subroutine is complex (it can handle various precisions, different language settings, and so on), the application has to set quite a few variables. Programs end up with hundreds of lines of code to set up, invoke, and retrieve the results from this one subroutine. But with the service program, I write a single procedure that accepts all the possible variables, and then the call requires only a single line of code, like this:

   Convert( wNUM: wALPH: 'M': 7: 2: '.');

I pass both the numeric field and the alpha field. This particular routine works that way natively. You clear one field and put a value in the other, and the routine determines which way to convert based on those values. This would also be the case when calling a program. All the parameters would be in the PLIST, and the calling program would pull the return value out of the list. Note, though, that at least in this case you can pass some constants. The prototype looks like this:

     dcl-pr Convert extproc(*dclcase);

      uNUM packed(29:9);

      uALPH char(29);

      iEDTC char(1) const;

      iDCCD packed(1) const;

      iFLDD packed(2) const;

      iDCFM char(1) const;

     end-pr;

So the two value fields, uNUM and uALPH, are specified at the beginning with large field sizes (these are the maximums for the routine). The rest of the fields are specified with the keyword CONST, which allows us to pass them in as variables, literals, or even calculated expressions. It's very powerful stuff. Oh, you may also have noticed that I used the keyword *DCLCASE on the EXTPROC statement. That will force the procedure name Convert to be declared to the rest of the system in mixed case. The default in RPG is to uppercase everything. I originally had to do this because of a bug in Rational Developer, but I think I may use mixed case for everything moving forward.

Now the Power—Order and Default

So you might be looking at this and saying to yourself that I didn't do much more than create a prototype for the subroutine, and that you could have done that without a service program by simply moving the conversion code to a standalone program and defining a prototype. Yes, that's correct. But now that we have the base procedure in place, the power of polymorphism come into play.

For example, I probably shouldn't have to specify the decimal separator over and over again. In fact, with a little forethought, I shouldn't have to specify it at all; it should at least be optional. And ILE RPG supports optional parameters just fine as long as they're at the end. All I would have to do is change the parameter definition slightly.

iDCFM char(1) const options(*nopass);

In my program, I skip the decimal separator:

   Convert( wNUM: wALPH: 'M': 2: 7);

The Convert routine checks for the parameter and if not passed, defaults it to something appropriate. That works well at the end of the parameter list, but a problem arises when an optional parameter is somewhere in the middle. For instance, if I find that I'm using edit code M most of the time, I might want that as the default. Unfortunately, the edit code is near the beginning of the parameter list, and I can't use the *NOPASS technique, because I will always specify the digits and decimals. You can't just skip a parameter in the middle of the list. Now, ILE does support a technique called *OMIT, which would look something like this:

   Convert( wNUM: wALPH: *OMIT: 2: 7);

In the called program, you can check for an omitted parameter using a little RPG magic, but the syntax is very RPG-specific and I've never been entirely comfortable with it. I would prefer not to specify unnecessary parameters at all, and with service programs that's easy to accomplish. In this particular case, I just create convenience procedures with only the parameters I need, in the correct sequence. These would be called Adapters in OOP terms. Here is one:

     dcl-pr ToAlpha char(15) extproc(*dclcase);

      iNUM packed(15:6) const;

      iFLDD packed(2) const;    

      iDCCD packed(1) const;

      iEDTC char(1) const options(*nopass);

      iDCFM char(1) const options(*nopass);

     end-pr;

This simple routine shows all of the power of service programs and prototypes. Remember that the original required that I use work variables that are passed to the procedure. So, in addition to the call, I'd also have to do some data movement. Here's the entire sequence to convert a numeric value in ORQTY to a display value in XQTY:

   wNum = ORQTY;

   clear wALPH;

   Convert( wNUM: wALPH: 'M': 2: 7);

   XQTY = wALPH;

This is in addition to a couple of DCL-S statements to define the work variables wNUM and wALPH, and it closely mirrors what you would do with an external program using a PLIST. But with the convenience procedure, the code is much simpler:

   XQTY = ToAlpha( ORQTY: 7: 2);

I moved the less-used parameters to the end of the procedure, so it's easier to leave them out. I swapped the number of digits and number of decimals to the order we're more used to seeing in RPG BIFs. But there's also one very important additional feature. The application software has two default sizes: high-precision internal 29-character values and the more commonly used 15-character variants used in database files and displays. I changed the width of the parameters on the convenience methods to use the more common sizes. The convenience procedure ToAlpha widens the data before calling the base procedure Convert and narrows the result before returning it to the caller. Also, I have one procedure dedicated to taking a number and converting it to alpha; another procedure (ToNumber, not shown here) converts an alpha value to a number. Because ToAlpha returns a value instead of updating a work variable, I can directly assign the result of the call to my target variable. I can't emphasize enough how important that becomes as you build more-powerful libraries of procedures. Finally, my default edit code is M and my default decimal separator is a period, which means conversions become very simple. I don't need work variables and can omit the defaults, so all the work is done with a single, easy-to-read line of code.

And perhaps the most important thing to remember is that all the convenience procedures still call the base procedure Convert. Because of that, any fixes or enhancements to Convert are automatically available to all the calling programs. And because they use a service program, they don't even have to be recompiled. To me, this is the best way to architect your applications to build immediately functionality but provide future-proofing at the same time.

Other Characteristics of Service Programs

While polymorphic behavior is probably the most immediate tangible benefit of service programs, service programs provide many more advantages. Another critical area is inter-communication among parts of your application. Service programs allow you to define data that can be shared between procedures in a module, between modules in a service program, and even among all the programs that call the service program procedures. The service program can initialize variables and keep track of state, if you design it to do so. We'll look at these and other capabilities in another article.