What Binding Language Doesn’t Do

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

Please see the previous articles here: Binding Directories and ILE Binding Language, Part 1

Not to start on a negative note, but I thought we would begin by looking at a couple of things that binding language doesn’t do.

Binding Language Is Not Needed for Export

I know I have seen articles that say that for certain types of exports you need to use binding language. Specifically, for cases where you are calling a service program sub-procedure from a program outside of the service program module.

But that’s not what my testing shows. Just for the record here, when I am using service programs I try to be good and follow all the rules. So I don’t spend my days doing weird things. Seems like a waste of time. But for this book I did try weird things to see how far the rules can be bent. I see no evidence that you have to use binding language for certain types of exports.

Binding Language Doesn’t Prevent the Wrong Sub-Procedure from Being Called

OK, this relates to what we said in chapter 19 about the fact that it is possible, in a service program, to call the wrong sub-procedure. And, again, I have seen articles that imply that using binding language prevents this from happening, and I think that is a bit of an overstatement. Now, this will take a few minutes, but stay with me.

Suppose you have a service program that has more than one sub-procedure. Let’s say it has two. And let’s say that they are Procedure1 and Procedure2, listed in the service program in that order. Feel free to follow along at home with this one using a service program you have written. By this time, it shouldn’t be any big deal at all to write one.

Start by creating a binding language source for that service program, with the sub-procedures listed with Procedure1 first and Procedure2 second. Save that in QSVRSRC.

Next, just to make sure we are kosher, let’s compile the service program in the procedure 1-2 configuration using the CRTRPGMOD and CRTSRVPGM combo with the EXPORT parm set to *SRCFILE (that is, we will be using binding language). Be sure to do the CRTRPGMOD so that you can get into debug.

Then compile your calling program, set to call Procedure2, with CRTRPGMOD (again set up for debug), and then CRTPGM to tie everything together.

Set a breakpoint in the calling program where you call the sub-procedure and start the program. Use F22 to jump into your service program, and you should jump in at the start of Procedure2. So far, so good.

Now go into the source for the service program and move Procedure1 so that it is after Procedure2. Go ahead, I will wait. And then, recompile it (first as a module: CRTRPGMODW with debug, and then CRTSRVPGM, again using *SRCFILE). But don’t recompile the calling program. We want a way to be able to change the service program but not have to recompile the calling program. You have to recompile the service program, of course, because when the program runs, the IBM i doesn’t run the source but the object. Am I being too elementary?

Now, call this service program from a calling program that is calling Procedure2. Put the calling program in debug and use F22 to jump from calling to called (the service program). What sub-procedure is accessed, Procedure1 or Procedure2?

And the answer is Procedure1. Even though Procedure2 is now the first sub-procedure in the service program, the compile with *SRCFILE has used the binding language list in QSRVSRC, and we have picked up the second sub-procedure (Procedure1).

Now go in, and just do the CRTSRVPGM using *ALL as the EXPORT parm. Then redo the CRTPGM so that you pick up the new service program, and repeat your test. Which sub-procedure is picked up? That’s right. This time you pick up Procedure2. *ALL has generated a new list of all modules with the EXPORT keyword on the P-spec.

Now at this point, binding language aficionados will say, “but you need to change the binder source when you switch the order of the sub-procedures,” and they are right. If we had changed the binding language source file when we swapped the sub-procedures and compiled the service program using *SRCFILE, then we would have ended up calling the right sub-procedure.

But you can also argue that if you hadn’t used *SRCFILE, that is, if you hadn’t used binding language, you wouldn’t have run into this.

And because of that, right now you are probably thinking, “I ain’t using no binding language,” but it may not be that simple. You will want to hold off making a decision until we go through signatures in the next chapter.

Does This Really Happen?

Of course, any normal person at this point will say, “but who is going to move their sub-procedures around in a service program? Is this really going to happen in the real world?”

Let’s skip the fact that I might rearrange things in a service program so that like modules are near each other (a total waste of time, but one that sounds like the kind of thing I would do).

Rearrangement doesn’t happen, but often it occurs when you add or delete sub-procedures from a service program. That will push a given sub-procedure up or down in the list position and so is where you might run into this.

For this reason, it is recommended that you add new items to the bottom of your service program. But that in itself doesn’t fix things. You still have to recompile and rebind, and so you still have the situation described above.

Besides, if you add or delete sub-procedures, then you run into signature violations, and that will catch you before you can run the wrong sub-procedure. But that is a topic for the next chapter.

That doesn’t sound real positive, does it? I was just rereading this as part of the edit. But service programs are definitely worth doing. Just keep things as simple as you can.

What Ya Shoulda Learned

As in the previous chapter, our recap is pretty straightforward.

First, you should be able to describe the difference between (or what each one does) both binding language and binding directories.

Second, you should know where both of these entities are kept. That is, are they a command that creates an object, or a source file that contains instructions, or what?

Third, can you remember some of the source/command verbiage that you would have to use?

Fourth, do you remember how each one is used? That is, what its purpose is?

And finally, were you able to stay awake during the discussion of how binding language, if not used correctly, can result in the wrong sub-procedure being called? Granted, it is not the normal situation, and it won’t happen every day, but it could happen, so be careful.