As you might guess, service programs are not a one-size-fits-all kind of thing, and where there is flexibility, there is often complexity. It’s not a lot, but there are a few additional things you should know in order to fully understand and set up your service programs for maximum efficiency.

Editor's Note: This article is excerpted from chapter 18 of 21st Century RPG: /Free, ILE, and MVC, by David Shirey.

So let’s take a look at what those things are before we go any further.

Binding

Let’s start by quickly reminding ourselves what binding is and how it fits into the ILE environment.

Binding is nothing new; it has been around for a long time. It is the process of relating two programs together (the calling and the called programs) so that when you access one from the other, much of the overhead is already taken care of and the whole “call” thing goes quicker.

Of course, you are not forced to do binding. BOPs (Big Ol’ Programs) do not worry about binding. You do everything in one program. There are no calls, no binding, no worries. There is also, probably, no way that you can reliably enhance or modify this thing after a few years go by.

But anytime you are calling one program from another, you are using binding. This, of course, is exactly what happens in a modular environment, and the basic thrust of ILE is in that direction. There are two flavors that this binding comes in: dynamic and static.

Dynamic sounds better, doesn’t it? Everything that is dynamic is better than something that is static. But that is not always true, and it happens that for us, static is better than dynamic.

Dynamic Binding

This happens when neither the calling nor the called program knows anything about the other. It’s like a big surprise birthday party.

That is, you don’t do any kind of pre-compile binding, you just compile each program separately, and then call one from the other. Suddenly, when the call occurs, the two programs become aware of each other and form a connection.  All of the overhead responsible for the “call” happens at this point, and so if this is a connection that happens many times while the app is running, it can become excessive and contribute to slow response time.

It is nice, because you don’t have to plan ahead for this. It’s also nice because since the bind happens when the programs run, we can modify them independently of each other. That is, I can change the called program and not have to redo the compile/bind of the calling program. But it’s bad because it can really slow things down if the connection happens repeatedly. Dynamic binding is old-school.

And how do you get dynamic binding? Remember? Just compile the calling and the called program separately. The call between the two will then function not knowing a thing about the other program.

Static Binding

Static binding is the opposite. It is planned and prepared for ahead of time, with much of the work being done at compile time.

In order to set up static binding, you need to follow a two-step process. You start by creating modules (*MODULE) for all the programs involved (CRTRPGMOD or PDM option 15), and then tie them together to form a program with CRTPGM where you list the modules involved.

The advantage here is that you get a lot of the overhead out of the way when you do the compile, and so you have a very fast connect.

The disadvantage is that you have to think ahead and take preemptive action. That’s harder for some folks than others. It’s also a problem because now, since we bound them together when we compiled them, if either program changes, we need to recreate the changed modules and rebind them together.

And how do you get static binding set up? Simple, just compile both the calling and the called programs as modules (CRTRPGMOD, PDM option 15), and then issue the CRTPGM command to tie the two together.

Now I want to be clear here. This is not ILE. This is the way it has always been. But in the ILE world, static binding is preferred over dynamic binding. I wish they had called it “good binding” and “bad binding”; it would be easier to remember then, but nobody asked me what I thought. Story of my life.

What Does This Have to Do with Service Programs?

Service programs make use of binding, but the situation is a bit more robust than the chocolate-vanilla situation just described.

To start with, let’s remember that a sub-procedure cannot exist on its own: it must be embedded in a service program or a regular program. And if it is in a regular program, you cannot call the sub-procedure by itself; you have to call that program as a whole and then somehow get into the sub-procedure. Only a service program can house a sub-procedure and let you call it separately from the rest of the sub-procedures in the service program. And only the service program uses the H-spec, NOMAIN, which removes the main cycle processing from that program.

In other words, service programs are a bit different from “normal” programs. And how they handle binding is a little different as well. To see this, let’s review how you create a service program block (the service program and the calling program).

You start by converting your service program source to a module.

Despite what you might think, this is a required step. Even if you choose all the defaults, you cannot create a service program unless that service program first exists as a *MODULE. Bottom line: you need to do this. Keep in mind, this is the “compile” per se, and so if you want to debug or anything, you need to specify it in the command or with an H-spec.

CRTRPGMOD MODULE('service program ID')

Then, you turn that module into a service program.

CRTSRVPGM SRVPGM('service program ID') EXPORT(*SRCFILE or *ALL)

That is fairly simple, and we will talk later (chapter 21) about the difference between *SRCFILE and *ALL in the EXPORT parm. For the moment, let’s use *ALL even though that is not the default.

The next step is to convert the calling program to a module.

CRTRPGMOD MODULE('calling program ID')

This can be done before or after you do the CRTSRVPGM. What is important here is that before the next step you have a service program (the output of the CRTSRVPGM) and a program module for the calling program (the output of CRTRPGMOD for the calling program).

The final step is to then create the final, bound program that combines both the calling program and the service program.

I generally name this program the same as the calling program (since we have only created that as a module so far), but you don’t have to do it that way (you can name this program whatever you want).

Now, what is interesting is the last parm, BNDSRVPGM. It actually consists of three pieces.

The first is the name of the service program module that is being bound in.

The second is the library that this service program module lives in. Prior to 7.3, this had to be a physical file in a library. But with 7.3, it became possible to include a stream file as the source of the source.

The third is the one that is interesting because the available values are either *IMMED or *DEFER. And it is the choice here that makes all the difference in how your service program works.

If you specify *IMMED, then the two programs (your calling program and your service program) are bound together at the time that the compile is done. This is static binding in that now your calling program and service program modules are bound together, and if you change the service program, you are going to have to not only recreate the service program but do the CRTPGM command again to bring in the new source for the changed service program. But it is really fast.

If you specify *DEFER, then the bind is delayed until you call that service program from the calling program. This is not quite as efficient because that overhead work gets done when you do the call, but it also means that since the service program source is not bound in at compile time, I can change the service program and not have to create the calling program all over again. If the service program you have changed is used by a large number of calling programs, this can save you a great deal of time.

It is not obvious from the command, but the default if not entered is *DEFER.

Which one should you choose? It depends on what you want. Do you have a service program that is used by a large number of other programs and which may be likely to change? Then using *DEFER is probably a good option. If, however, you don’t think the service program is likely to change and/or it is not called from that many places and you’d like to reap the extra efficiency, then *IMMED might be a better choice.

One final thing I should mention is that you might very well have multiple service programs bound to a single calling program (for example, if the calling program calls multiple sub-procedures from multiple service programs). This can be handled quite simply because you can enter multiple BNDSRVPGM parm sets. It is also a good time to bring in binding directories, which we will discuss in the next chapter.

What Happens When You Call a Service Program?

OK, we now have a handle on binding service programs and what some of the pros and cons might be in using them.

In a few minutes, we will look at some of the types of problems, er I mean situations that you can run into when working with service programs.

But before we do that, I want to take a closer look at exactly what happens when a program calls a sub-procedure in a service program.

We know from chapter 10 that the call occurs when we issue a CALLP with the object being the name of the sub-procedure that we want to access. There is no information in that call about the name of the service program that contains that sub-procedure, so how does the system find it?

That should be an easy-to-answer question because we saw a page or two ago that when we do the CRTPGM and bind the calling and service programs together, we actually specify the service program name(s).

So now we have two pieces of information: the sub-procedure name from the CALLP (or rather, actually from the PR D-spec EXTPGM parm), and the service program name(s) from the CRTPGM command (either via the BNDSRVPGM or the BNDDIR parm).

The logical thing to think at this point is that the i starts with the first service program listed in the CRTPGM and begins searching through till it finds a sub-procedure whose name matches the one from the calling program’s PR D-spec. But life is rarely as simple as we envision it.

The i does indeed search, but it does not go through the service programs. Instead, it searches through a list that is associated with the service program. Where does this list come from? Hang on. For the moment, just know that it looks through the “list,” finds an entry that matches the sub-procedure name from the calling program PR D-spec, and then notices what sequential number that sub- procedure name is in the list. Let’s say it is the third one down.

The i then goes out to the service program already identified and finds the sub-procedure with the same sequence number, in this case the third one in the service program, and with complete disregard for what the name of this sub-procedure might actually be, executes it because the position in the service program matches the position in the list.

One thing you might be wondering about here is where in the service program does the system look? Does it look at the list of PRs or at the actual procedures in the program? Normally these will be in the same order, but not necessarily. As it turns out, the system goes through the actual source of the program and ignores the PRs in trying to determine which sub-procedure is called.

The other thing you might be wondering is: why does IBM do this? Why do they look at a list and then use a relative position in that list rather than just looking for the sub-procedure in the service program? And the answer is, efficiency. It is much faster to look in a short list, then determine the relative position in that list (like the index of an array), and then find that position in a service program than it is to search through a service program looking for a name match. This makes sense, but it does leave some room for problems if you are not careful. More on that later.

Anyway, the next question is: where does the list come from? Well, if you compile your service program (CRTSRVPGM) with the EXPORT (Export Source Member) keyword set to *SRCFILE, then the system will look for a binding language source member to use as that list. If one does not exist, there will be a compile error. The spot where this source file is located is then given by the SRCFILE and SRCMBR keywords. We will talk about binding language in chapter 20, but for now just know that you have to set up your binding language source file before you compile your service program, if you are using it.

But if you set EXPORT to *ALL, then the system will, during the compile, look at the service program and create its own behind-the-scenes list that shows the order of the sub-procedures in that service program.

And this is the list, whether created by you via binding language (see chapter 20) or auto-created by the system, that will be used to find the position of a sub-procedure in that service program. It does not throw this list out into a source file so that you can see it, but it creates an object list just the same.

And don’t worry about the binding language references above. We will cover that in chapter 20.

What Can Go Wrong

Of course, any time you have a lot of flexibility and options, things can go wrong. I suppose that is not the best way to sell service programs, but sometimes bad things happen to good things.

So what do you need to watch out for in terms of service programs?

Calling the Wrong Sub-Procedure

Yes, it may be hard to believe, but you can actually call the wrong sub-procedure in a service program. That is, you might have sub-procedures A and B in the service program, and you mean to call A, but you end up kicking off B instead.

The primary reason for this is because of the “finding things by relative list position” thing. If we picked them up by name instead of their spot on a list, this wouldn’t occur. But we don’t, and so it can.

The good news is that it only happens in a very specific circumstance, and there are a number of things you can do to minimize the chances of this ever happening. We’ll discuss this in detail in chapter 20.

Signature Violations

The second thing is what is known as a signature violation. I won’t go into all the details here. See chapter 21 for the whole ugly story. We will just say that the service program signature is similar to a level check except that it is quite a bit different. But you’ll see when we get there.

Other than that, it’s pretty bulletproof. And very handy, so don’t decide you don’t want to do service programs because you might have one of the two problems mentioned earlier. That would be very short-sighted indeed.

What Ya Shoulda Learned

The main emphasis here is on binding.

We start with the classic definitions of static and dynamic binding and look at how they relate to even OPM programs.

The next step takes us back through the compile process for a service program and its calling program because they are treated a little differently from regular programs.

As part of this compile review, we saw that we have a number of parms in the compile commands that exert a great effect on the objects. Specifically, we have *SRCFILE and *ALL on the EXPORT parm of the CRTSRVPGM, which we will talk about in chapter 20, and the *DEFER and *IMMED values on the BNDSRVPGM parm of the CRTPGM command.

We talked about the *DEFER and *IMMED values here and saw that using *IMMED causes the calling program and service program to be bound at compile time the way a normal bind works. *DEFER, on the other hand, doesn’t actually bind until the run occurs. Both methods have their pros and cons, and you should be able to describe what those benefits/weaknesses are. Can you?

We then went on with a blow-by-blow description of the sequence of events when a program calls a sub-procedure in a service program.

Finally, we named the two things that can happen to cause problems when you are accessing a service program. Can you tell me what those two problems are? We promised more details on them in a subsequent chapter.

And that’s about it. But time wanes, and we must move on. There are two things that you keep running into when you talk about service programs: binding directories and binding language. Let’s dive into them next and see what all the fuss is about.