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:
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.
It’s the holiday season, and everyone is in the gift-giving mood. Be sure you don’t forget to invest in your company and career.
Written by Brian May
It’s a special time of the year. Family gatherings for the holidays, football season, and time in the woods all make this one of my favorite seasons. The month of December is also unique for IT departments. December is certainly not business as usual for most of us.
It’s time for budgets. That may mean requesting budget items for next year or spending surplus budget before the end of the year. It’s often when project work slows down a bit as end users, and IT staff alike, take time away from the office. It’s a time when stress is often at its lowest, and it’s just easier to get some things done.
A more “modern” alternative to STRSQL, discussed in the last two articles, is the i Navigator’s Run SQL Scripts tool. Let’s explore it together, shall we?
Written by Rafael Victória-Pereira
While STRSQL is a green-screen tool, Run SQL Scripts is part of the i Navigator package. You can access it by choosing the Run SQL Scripts option, either from the bottom-right pane of the i Navigator window after you’ve chosen the Databases tree node from the right panel, as shown in Figure 1, or by right-clicking the database name and choosing the respective option.
This is IT. We must be willing to bend.
Written by Steve Pitcher
With a growing emphasis in talking about the state of the current IBM i workforce, also known as the “IBM i skills shortage,” it behooves oneself to keep the noise level to a minimum in order to make even-keeled decisions. In short, don’t necessarily believe all the hype you read.
I’d like to think of this as an extension piece to “The IBM i Skills Shortage Myth.” It’s not necessarily a “part two” per se, but more of a story that runs parallel. I’ve been trying to write this for about six weeks, but some things are just hard to put into words, especially when they involve how you feel as opposed to what you know. Besides, writing what you know is easy. Writing what you feel leaves room for reader interpretation, so you have to be more careful.