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.