The previous article of the series discussed module and service program organization. It’s now time to do the same for binding directories.

Let’s start with a quick recap of binding directories. Your modules will be composed of procedures. Some of these procedures are going to be available to the outside world; these are the module’s exports. The module’s procedures might call procedures from other service programs; these are the module’s imports. The problem is that the compiler has no idea where to find those procedures that your module’s code is calling, if they don’t belong to the same module/service program.

A binding directory is a list of modules and/or service programs that the compiler will use to discover where to get the information it needs about the module’s imports. Regardless of how your modules are organized, you can create as many binding directories as you see fit. There are a couple of ways to go about this:

First method: Create one binding directory per application. You include all the service programs of the application, no matter how they’re organized, in one big binding directory. This way, you use the same binding directory in the creation of all programs and service programs of that application. You might have a few more binding directories, dedicated to tools like CGIDEV2 or MIME&MAIL, for example.

This scenario is the simpler of the two to manage, because there are only a few binding directories. You might think that the compiler will take longer to run through the binding directory to “connect the dots” between your program and the binding directory; however, this is not true, because the binding directory doesn’t contain the actual objects. It’s a list, not a repository, so the compiler will pick only those that are really needed to create the program, and ignore the rest.

Second method: Create one binding directory per program/service program. You have a tailored binding directory per program/service program, which includes only the objects (modules and/or service programs) needed to create each specific program or service program. In this scenario, the binding directory serves a double purpose, both “connecting the dots” as I explained in the other scenario, and serving as “mini-documentation” in conjunction with the procedures it holds.

Let me explain what I mean with a little example. Imagine that you have a procedure named Clc_Delivery_Fee, and the binding directory of the service program its module belongs to includes another service program named ORDDBO. Assuming ORDDBO stands for order management database operations, you can conclude that the aforementioned procedure uses data from the order files to calculate the delivery fee. This is an assumption impossible to do in the other scenario, because the binding directory has a much broader scope. However, you have a lot more binding directories to manage than in the previous scenario.

Personally, I favor the one-binding-directory-per-service-program scenario. That’s probably because I’ve worked in an ILE environment configured that way for many years, so I’m more comfortable with it. I also prefer the one-service-program-per-module approach for the same reasons. This approach standardizes object-creation commands, it helps you follow a coherent design and development methodology, and it’s easy to use, once you get used to it and you document it properly. But that’s just me! Because you’re probably not starting from scratch, your application might have some sort of standard that can be extended to accommodate service program and binding directory organization.

I’d like to take a moment to do a quick recap of what was discussed in the last few TechTips before diving into the much-awaited topic of documentation:

• Following some sort of naming convention facilitates communication, helps integrate new members of the team more quickly, and reduces the time spent trying to “figure out what that variable is used for.” Proper variable prefixes and names (instead of x, y, and i) improve the code’s readability and maintainability.
• Similarly, using descriptive and structured names for your procedures is very helpful; it’s a big step toward turning your code into an easy to read, easy to maintain narrative. (Free-format will also help with this, as you’ve seen in the “/FREE Your Code” subseries.)
• Using prefixes for files goes a long way when it comes to understanding what’s going on in your data; quickly figuring out if that is a physical or logical file just by looking at its name will save programmers (and users) some valuable time.
• Organizing your code is of paramount importance. You need to find a logical and intuitive way to organize your procedures into modules and your modules into service programs so that when you need to use them to build a new program, the task is almost as easy as putting some Lego blocks together. And don’t forget the binding directory organization discussed earlier in this article!

You might think that these rules are not relevant in your particular environment, but over time you’ll see that they really help save time (and quite a few headaches) whenever you have to go back to code you, or a fellow programmer, wrote some time ago.

However, when it comes to figuring out what the code does, proper documentation is critical! Stay tuned, because the next TechTip will cover this interesting and often overlooked topic.

Rafael Victória-Pereira has more than 20 years of IBM i experience as a programmer, analyst, and manager. Over that period, he has been an active voice in the IBM i community, encouraging and helping programmers transition to ILE and free-format RPG. Rafael has written more than 100 technical articles about topics ranging from interfaces (the topic for his first book, Flexible Input, Dazzling Output with IBM i) to modern RPG and SQL in his popular RPG Academy and SQL 101 series on mcpressonline.com and in his books Evolve Your RPG Coding and SQL for IBM i: A Database Modernization Guide. Rafael writes in an easy-to-read, practical style that is highly popular with his audience of IBM technology professionals.

Rafael is the Deputy IT Director - Infrastructures and Services at the Luis Simões Group in Portugal. His areas of expertise include programming in the IBM i native languages (RPG, CL, and DB2 SQL) and in "modern" programming languages, such as Java, C#, and Python, as well as project management and consultancy.

---

MC Press books written by Rafael Victória-Pereira available now on the MC Press Bookstore.

		Evolve Your RPG Coding: Move from OPM to ILE...and Beyond Transition to modern RPG programming with this step-by-step guide through ILE and free-format RPG, SQL, and modernization techniques. List Price $79.95 Now On Sale
		Flexible Input, Dazzling Output with IBM i Uncover easier, more flexible ways to get data into your system, plus some methods for exporting and presenting the vital business data it contains. List Price $79.95 Now On Sale
		SQL for IBM i: A Database Modernization Guide Learn how to use SQL’s capabilities to modernize and enhance your IBM i database. List Price $79.95 Now On Sale

Also Read

Advanced/Free - Function Calls and Return Values

PRACTICAL ILE - ILE Service Programs

Data-Manipulation Operations Using Free Format, Part Two