RPG CODE COACH
ILE RPG Structure: subprocedures,
modules and service programs
Author: Craig Pelkie
Introduction to this Series of Articles
Read the Articles
Using subprocedures to create modules is one of the highest pay-off techniques available to iSeries RPG programmers. Although the primary benefit of "reusability" is usually cited as the reason to create subprocedures, I believe that is only one of several equally important benefits.
By forcing myself to code subprocedures and modules instead of subroutines in programs, I am subjecting myself to the discipline of compiler and operating system enforced rules. Because the rules at first seem to be restrictive and prevent the usage of many old-style RPG coding practices, many RPG programmers simply abandon the pursuit after a few feeble attempts at coding subprocedures. It is difficult to will yourself to continue to use techniques that are poorly understood, full of strange rules and constraints, and most importantly, don't seem to provide any of the promised benefits.
Based on conversations and email exchanges I've had with many RPG programmers, I believe the crux of the problem is that there has simply not been any extended discussion of how to construct subprocedures and modules. At this point, there are hundreds of examples of specific techniques that you can easilyfind on the Internet or in any of the RPG references, from IBM and other sources. The fact that RPG programmers are still expressing doubt about the importance of modular programming techniques, more than 10 years after their introduction into the RPG language, indicates a serious gap in understanding.
In this series of articles, I will not attempt to persuade you to use subprocedures and modules. I take it as a given that those techniques are desirable. Instead, I will show you many examples of how to code subprocedures and other supporting code required to create the types of robust modules that can be created using RPG. I won't spend a lot of time teaching you syntax rules; you have the RPG reference manuals for that. Instead, I'll tell you why I use certain techniques and prefer one or another technique over others.
Much of what I've learned about creating RPG subprocedures and modules is based on my experience with Java. It took me several years to get up to speed with Java, but I now feel quite comfortable using the language, if not with all of its intricacies and details. When I returned to RPG coding, I found that I could apply many of the commonly used Java techniques to RPG. I am not suggesting that you need to learn Java to understand my techniques, but I am pointing out that much of what I am showing you has direct analogs to Java.
It is likely that you will disagree with many of my suggestions, as the code that I present does not look like code that is usually written using RPG idioms. In all cases, it is important to remember that I am not suggesting that you adopt my techniques until and unless you are convinced of their value for your coding. I am simply showing you some of the techniques that I have developed, adopted and internally codified for my use. The techniques have served me well for the dozens of modules and hundreds of subprocedures I've coded over the past few years. In all cases, I am open to learning and modification when I encounter better ideas based upon software engineering principles that are widely understood and accepted in the programming community at large, not simply the pool of RPG programmers.
Read the Articles