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!

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