Make compiling easier for service programs with the use of binding directories.

With the end of the year comes time to close out my series of articles on service programs. In previous articles, I discussed how to create a service program, followed by discussing the benefits and cautions of using the binding language with your service programs. In this article, I'll discuss how to create binding directories and why you would want to use them.

For your reference, here is a complete list of articles in the series:

• "How to Create, Compile, and Use Service Programs"
• "Using Binding Language with Your Service Programs"
• "Features and Cautions of the Binding Language"

What Are Binding Directories?

Binding directories contain a list of service programs or modules to bind to your program. Your RPG program can use this directory so that you don't have to specify all of this information when you compile your program.

Because the term "binding directory" is similar to "binding language" I immediately assumed that the binding language was the code to generate the binding directory, which is not true. I had a hard time shaking that concept, which was initially a source of confusion for me.

To drive the point home, the binding directory and binding language are two completely different things:

• The binding language specifies the interface to the service program and modules. It's associated with the program during compile time and will assume that the interface hasn't changed if the signature associated with the service program remains the same.
• The binding directory lists all of the service programs to reference from the program and is used by the compiler to validate the existence of the references that you're making.

The concept of binding directories is similar to library lists in that they will tell you to look for the service programs in specific locations. The order in which the service programs are listed in your binding directory are meaningful, just as with a library list, because the program will look through the list in the listed order until it finds the reference the compiler is looking for. If you're familiar with Java, this concept is similar to class paths.

Why Use Binding Directories?

As with most things, I'm sure there are multiple reasons why you would want to use binding directories, but my primary reason is simply because they make it a lot easier to compile your programs. To keep your service programs organized, you may have multiple service programs that each provide functionality in different areas. As your service programs become more robust and your main programs start utilizing more service programs, it would become cumbersome to always have to remember and specify each of these service programs during compile time.

If you put your service programs into binding directories, then you can specify the binding directory of interest in the H-specs of your RPG program and not have to list them when you're creating the program.

How to Create Binding Directories

It's time for us to dig into some examples to illustrate the use of binding directories. We'll start by creating a binding directory that will contain the service program that has been referenced in the previous three articles (listed in the opening paragraph of this article).

In the articles leading to this one, we created a service program called MCPSRVPGM, which contains the htmlEncode and htmlDecode procedures to convert special HTML characters. The logic isn't referenced in this article; instead, we'll focus on the compile process for the program using the service program.

We'll name our binding directory MCPBNDDIR and will execute the following command to create our binding directory:

CRTBNDDIR BNDDIR(MYLIB/MCPBNDDIR) TEXT('MC Press Binding Directory')

When the CRTBNDDIR command is executed, we have an object created of type *BNDDIR that is empty. To add the MCPSRVPGM service program to the binding directory, we could use the command ADDBNDDIRE, which will add a binding directory entry into the binding directory:

ADDBNDDIRE BNDDIR(MYLIB/MCPBNDDIR) OBJ((MCPSRVPGM *SRVPGM *IMMED))

Or we could work with the binding directory and add the service program interactively using the WRKBNDDIRE command:

WRKBNDDIRE BNDDIR(MCPBNDDIR)

When you work with the binding directory, you can add a service program with the 1 option. You can also see the list of service programs that already exist within the list.

Figure 1: WRKBNDDIRE allows you to add service programs and see existing service programs. (Click images to enlarge.)

In previous articles, we referenced the service program during compile time as follows:

CRTPGM PGM(MyLib/MCP047RPG) BNDSRVPGM(MCPSRVPGM) ACTGRP(*NEW)

The previous command doesn't seem too bad, but what if you had a couple of additional service programs called MCPSRV2 and MCPSRV3 that you were also using from your program? Your new compile command would now look like this:

CRTPGM PGM(MyLib/MCP047RPG) BNDSRVPGM(MCPSRVPGM MCPSRV2 MCPSRV3) ACTGRP(*NEW)

You can see that the CRTPGM command is now becoming longer, and it would also become difficult to keep track of what service programs to include. If we were to put all the service programs to be used into a binding directory, we could reference the binding directory during the compile, so we'd be specifying only one reference to multiple service programs during the compile as follows:

CRTPGM PGM(MyLib/MCP047RPG) BNDDIR(MCPBNDDIR) ACTGRP(*NEW)

But we could take it a step further by specifying the binding directory in the H-specs of the RPG source as follows:

H BNDDIR('MDCBNDDIR') DFTACTGRP(*NO) ACTGRP(*NEW)

And now our compile could look like this:

CRTPGM PGM(MyLib/MCP047RPG)

And that's not all. Because we no longer need to specify the service program or binding directory, we could revert back to the good old CRTBNDRPG command:

CRTBNDRPG PGM(MyLib/MCP047RPG) SRCFILE(MyLib/QRPGSRC)

By using CRTBNDRPG you can eliminate the two-step process of creating the module and then creating the program. 

Coming Full Circle

As we started discussing service programs and the binder language, the process of compiling the programs seemed to become more and more complicated with new commands to learn and more things to remember during compile time. But, with binding directories, you can eliminate all of that and even revert back to the good old CRTBNDRPG command to create your programs because all of the details are handled within your RPG program itself. So set it in the H-specs and forget it!

Giving a Shout-Out

I have to give a shout-out to my boss, Mr. James B. Staton, for introducing me to most of the topics in this series. I was struggling with maintaining service programs without the binding language and binding directories for the longest time, and I'm very appreciative for these newfound capabilities.

I started out with service programs with the sole purpose of coding modularity, and once I had what I needed, I drew my line in the sand to begin producing results. But, thanks to Jim, I was pushed a few steps over that line to provide the complete solution with capability and ease of maintainability.

Merry Christmas and Happy New Year

I thank you for reading my articles and making them as popular as they are. And I wish you a Merry Christmas or Happy Hanukkah, Kwanzaa, or Festivus—essentially, Happy Holidays however you celebrate the season!

And now you can start off the New Year with a fresh perspective on your coding style with service programs!

Thomas Snyder has a diverse spectrum of programming experience encompassing IBM technologies, open source, Apple, and Microsoft and using these technologies with applications on the server, on the web, or on mobile devices.

Tom has more than 20 years' experience as a software developer in various environments, primarily in RPG, Java, C#, and PHP. He holds certifications in Java from Sun and PHP from Zend. Prior to software development, Tom worked as a hardware engineer at Intel. He is a proud United States Naval Veteran Submariner who served aboard the USS Whale SSN638 submarine.

Tom is the bestselling author of Advanced, Integrated RPG, which covers the latest programming techniques for RPG ILE and Java to use open-source technologies. His latest book, co-written with Vedish Shah, is Extract, Transform, and Load with SQL Server Integration Services.

Originally from and currently residing in Scranton, Pennsylvania, Tom is currently involved in a mobile application startup company, JoltRabbit LLC.

---

MC Press books written by Thomas Snyder available now on the MC Press Bookstore.

		Advanced, Integrated RPG See how to take advantage of the latest technologies from within existing RPG applications. List Price $79.95 Now On Sale
		Extract, Transform, and Load with SQL Server Integration Services Learn how to implement Microsoft’s SQL Server Integration Services for business applications. List Price $79.95 Now On Sale