The second step in service programs is telling the world about your procedures, and that's done through prototypes.

In our previous article, we began to explore how to build a library of service programs. We reviewed some procedures that you might find in a service program and explained how they were related and why they were built that way. Now we need to use those procedures, and the first step to doing that is to let the rest of your applications know the procedures exist. This is done through prototypes. As your library grows, so will your list of prototypes. This article presents a programming infrastructure you can use to manage that growth.

First, the Prototypes

The initial article outlined a service program with three procedures: CredCalcDates, CredGetProx, and DateSetDay. I presented those procedures in a sort of shorthand, with just the procedure names and some representative names of parameters. Here's the list:

CredCalcDates( currentDate: netDays: discDays: proxDay: dueDate: discDate);

CredGetProx( currentDate: proxDay);

DateSetDay( currentDate: dayNumber);

While that provides a rough outline of the procedures, it doesn't provide a lot of meaningful information about the procedures. Now it's time to see the real prototypes in detail. Let's first use the traditional prototype definition. Let me show you the prototype for DateSetDay.

     **

     * Compute date by setting the day of the month to a specific value

     **

     d DateSetDay   pr              d

     d iDate                      d const

     d iDayOfMonth              3u 0 const

If you work your way through the D-specs, you'll see that DateSetDay takes two parameters: the date and the day of the month. It returns the new date. The code is concise, but in fixed-format RPG that conciseness is sometimes overdone to the point of incomprehensibility. As an alternative, I'd like to show you what the free-form version of this prototype looks like:

     //

     // Compute date by setting the day of the month to a specific value

      //

      dcl-pr DateSetDay date;

       iDate date;

       iDayOfMonth uns(3);

      end-pr;

The more I use free-form RPG, the more I like it. Some of it is still a little obscure. The keywords dcl-pr and end-pr don't exactly jump off the page with intuitive understanding. Other than that, though, I think the coding for the prototype is pretty straightforward. (Okay, the definition of binary numbers in RPG is and will always be a little arcane, but it's not egregiously difficult and at least you don't have to senselessly specify zero decimal positions.) It takes a little getting used to, but I find that once I've gotten into the free-form rhythm, I can just keep coding. I can even do green-screen programming faster. The other day I put together a quick test program to exercise some new calculations, and it took almost no time. I popped into the Screen Designer in RDi (Rational Developer for i) and threw together a quick screen, and then I just banged out the code. The workstation file was defined just this quickly: "dcl-f MYDSPLY workstn;". I coded a quick exfmt loop that called the procedure with fields from the display, and I was done with the program.

Now, the Copybooks

Okay, we've seen that it's pretty easy to create the prototypes. Now we have to get those prototypes to our calling applications. By far the most appropriate way to do this is through the use of a /COPY statement. Most RPG programmers have used these during their careers, and the concept is called by several different terms: includes, copybooks, and copy members are just a few of the terms. Even my favorite term, copybook, has variants: it can be either one or two words. For consistency within these articles, I'll stick with the term copybook.

Generally speaking, you code the prototypes into a source member (the copybook) and then include that member in your application program using the /COPY statement. This is a pretty simple technique, but it does require that you know the name of the copybook. If you have only one copybook, that's pretty simple, but as your environment expands, you'll find that you use more and more of them. You may also be using external copybooks, either from IBM or from other sources. And then one day the unthinkable happens: you have to rearrange your copybooks!

Let me give you a simple example. Let's say the above service program eventually grew to where there were a whole bunch of credit procedures. At the same time, you built a very comprehensive set of date-processing functions. At some point, it will probably make sense to split the DateSetDay procedure off of the Credit service program and move it to a separate date-handling service program (that utility service program may do more than dates, of course, but that will depend on your environment). In so doing, you realize that your old naming convention isn't going to cut it anymore. You had just one service program, CREDIT, and one set of prototypes in CREDPROTO. Here's the line of code in your program that includes the prototypes:

     /COPY QCPYLESRC,UTLDATPR

You sense that your service programs are going to multiply, and you're going to have to try to keep them straight with a solid naming convention. You quickly realize that you can drop back to your traditional IBM i technique of using three-letter abbreviations. So you come up with a naming convention: xxxyyySVC and xxxyyyPR, where xxx is the service program type and yyy is the actual application. Application logic goes into the type APP, while utilities go into UTL. SVC is the service program, PR is the copybook. And so you get APPCRDSVC, APPCRDPR, UTLDATSVC, and UTLDATPR. It all makes perfect sense, except that now you have to go into every program that uses the services and change the /COPY statements.

Nested Copybooks to the Rescue!

What we do instead is to create a copybook named COPYCOMMON that allows you to include all the other copybooks with simple /DEFINE statements. COPYCOMMON has code that looks like this:

     * Date handling

     /IF DEFINED(Copy_Dates)

     /COPY QCPYLESRC,UTLDATPR

     /ENDIF

     * Credit processing

   /IF DEFINED(Copy_Credit)

     /COPY QCPYLESRC,APPCRDPR

     /ENDIF

You can then include the credit routines with two simple statements in your program:

     /DEFINE Copy_Credit

     /COPY QCPYLESRC,COPYCOMMON

Now if you need to change the name of the credit prototypes, you need to change only one place. Note that you don't need to include the date-processing routines in your program; they're invoked by the Credit routines. But you could include them by simply adding a second /DEFINE that defines Copy_Dates. This technique allows you to copy all sorts of things, including standard includes that you might be familiar with:

     * CGIDEV2

     /IF DEFINED(Copy_CGIDEV2)

     /COPY CGIDEV2/QRPGLESRC,PROTOTYPEB

     /COPY CGIDEV2/QRPGLESRC,USEC

     /ENDIF

A quick and easy way to include both CGIDEV2 copybooks! This technique has a lot of potential, especially when you need common defines across multiple applications. And it gets us almost all the way through to using service programs. The last thing we need to do is bind them into our program, and we'll see that next. Until then, have fun with copybooks!