If you still write code as you did 20 years ago or have RPG ILE on your resume but don't actually use ILE, this is for you. This series will help you transition to RPG ILE by explaining the concepts of ILE, including the pros and cons.
I like it when my readers reach out to me with questions about my articles; every writer does. It means people are actually reading and trying to use the stuff I write about. However, I've noticed more and more that the questions are not about the Tips per se: they're about the foundations that every RPG programmer—whether novice or expert with 20 years of experience—should know. This TechTip series will (hopefully) guide the reader on a quest for better programming. Better skills, better standards, and most of all, more-efficient code. So, without further ado, let's get started!
From Old Problematic Monoliths to Innovative Light and Efficient Programs
The Original Program Model (OPM), or do-it-all-in-one-program model, has been around for many years. It served our purposes for many years (and it still does, in certain conditions), but it's rather limitative and inefficient. It leads to problematic monoliths of code—huge programs that have to handle the screen interaction, database operations, and report generation. Even if it's well-structured and commented, it can get very messy because the program is going to get huge. The worst part is, if you have a similar situation (same business rule or DB operation, for instance) in another program, you'll probably have the same code repeated in two programs.
ILE came to help with that: it provides a lighter way to build programs by allowing the re-usage of code, instead of its repetition. In other words, the shared code between programs that I mentioned earlier exists separately from the programs and in only one place. The programs will use that code as if it were its own. This allows the developer to construct the programs a bit like playing with Lego: use a building block to write a record, use another to check a business rule, use yet another to print a report, and so on.
But don't take my word about the virtues of ILE; let IBM convince you! According to the IBM manual ILE Concepts, the main advantages of ILE are:
- Modularity—Smaller, reusable pieces of code have shorter compile times and are easier to maintain. Smaller, specific functions (even if they were written in a style different than your own) are easier to understand and adapt. This also means that it's easier to test (from personal experience, let me tell you that this is not always true; I'll explain later). And finally, the work can be divided: each programmer can write a "building block" instead of the complete program.
- Reusable Components—As previously stated, ILE allows you to reuse pieces of code to build your programs. What you might not know is that these pieces of code can be written in other programming languages, such as COBOL, C, C++, and CL! Theoretically, this allows you to access a wider range of routines, providing the best each language has to offer. Again, I don't totally agree with this one; an RPG shop has RPG programmers. It might have someone who knows a little C, but that might not be enough to justify using C modules in your applications, because if that programmer leaves, the shop has a hot potato in its hands: code it can no longer maintain.
- Common Runtime Services—IBM supplies a very nice set of off-the-shelf components that you can incorporate into your applications. These components provide message handling, date and time manipulation, math routines, dynamic storage allocations, and greater control over screen handling. Again, from my experience, this is extremely useful. Not only are the tools ready to use; they're also well-documented in IBM manuals.
- Source Debugger—Every OPM programmer's worst nightmare is debugging a huge program with the Interactive Source Debugger. ILE brings forward a brilliant and simple debugger that turns that nightmare into a pleasant dream. (I'll talk about the debugger in a future TechTip.)
Those are just some of the main advantages, and I've intentionally left out the more complex. They'll be addressed later with examples.
It should now be easy to understand why every programmer should embrace ILE as soon as possible. This TechTip series will help you do that. In the next TechTip, I'll talk about some basic module, service program, and program concepts.
LATEST COMMENTS
MC Press Online