It’s important to keep in mind that the naming conventions are not limited to variables, procedures, and files. Since you’re starting with ILE and building your first modules and service programs, this is the perfect time to start doing it the right way.

I mentioned that modules should aggregate procedures/functions by action and/or subject. For example, you should put all the functions related to database operations over the inventory files in the same module, while putting all the business logic functions (validations, rules enforcement, etc.) in another module. The next logical step is naming these modules (and the service programs that include them) following a proper naming convention and keeping everything organized in a simple, logical, and practical fashion.

The fact that the system object names are limited to 10 characters doesn’t help, so you need to set and follow a few standards that you’re comfortable with. I’ve seen many different approaches to this problem. My favorite solution is the following:

If an application has clearly defined parts (like a typical ERP), you can assign a three-letter code to the part name and use another three characters to identify the generic task performed by the procedures/functions of the module (such as database access, business logic, or calculations).

For example, a module of the inventory management part of an application that aggregates all the database operations related to the inventory files could be named IVM_DBO (or IVMDBO): IVM for inventory management and DBO for database operations.

When you consider changing a monolithic application structure to something more modular, it’s important to identify all the generic tasks that your application performs and define an abbreviation for each of them. Then, go over the application structure and do the same for all the “application parts.” (I’m using the expression “application parts” instead of “application modules,” which is a much more common term, so that you don’t confuse them with ILE modules.)

Tips for Organizing Your Code

In a traditional OPM environment, your programs are isolated silos that work alone or with some helper programs, so the need for real organization doesn’t go beyond separate libraries for sources, files, and programs. In an ILE environment, the complexity is much greater; you have a multitude of modules, service programs, programs, and binding directories to organize and manage. In order to build a program, you’ll probably need a “main flow” module and one or more service programs, which might have one or more modules. In the example in Figure 1, repurposed from one of the first TechTips of this series, M1 and M2 are the “main flow” modules of programs A and B, respectively. Modules M3 and M4 are part of the C service program that is used by both programs. Just ignore the names; they’re bland on purpose to keep the focus on the structure.

Figure 1: This is a basic module, program, and service program scenario.

This complexity increases in real-life situations, in which a program might use 10 or more service programs (depending on how you decided to organize the modules). So you really need to organize your code; otherwise, all the productivity gains that ILE potentially brings will be lost.

How to Organize Your Service Programs

This TechTip started by showing how to name your modules. It’s now time to talk about how to group those modules in service programs.

The service program organization usually follows one of two approaches:

• Create one service program per module if your modules group all the procedures/functions of a given combination of “application part” and “generic task.”
• Group all the “application part” modules into a single service program.

Each of these approaches has advantages and disadvantages. While having one service program per module provides maximum flexibility and decreases compilation time, it also requires that you know where to find the procedures you need and add the appropriate procedure prototypes to your program. As I explained before, it’s simply a matter of using a /COPY statement, specifying the name of the copy member that contains the procedure prototypes.

The other approach doesn’t require you to know which service programs to include in so much detail because you have one for each application “part.” However, it might cause other problems, such as duplicated function names in different modules (if you don’t prefix your functions with the module name) and longer compilation times, just to name a couple. I’ve seen the one-service-program-per-module solution work better, once you know where to find the procedures needed. You need to choose carefully, though, because reorganizing everything in an ILE environment is tricky!

No matter what your choice is, you’ll need to include the procedure prototype definitions in the “main flow” modules (i.e., programs) that need to use them, using /COPY or /INCLUDE. The most practical way to do this is to create a source member in a separate file (I like to use QCPYLESRC) for each module. This copy member would include all the module’s procedure prototypes, as well as common data structures and constants used to call the procedures. If you have one service program per module, then you just need to include the service program names in a binding directory (ideally, they’ll be the same as the modules’)…or not, depending on your binding directory organization, which will be the topic of the next TechTip!

Without wanting to turn this into a war between “groupers” (people that prefer the one-service-program-with-many-modules) and “splitters” (the guys and gals that advocate one-service-program-per-module), I’d like to hear about your preference and the reasons behind it. Speak your mind in the Comments section below!