[IMAGE]
[IMAGE][IMAGE]
Ron Turull
[IMAGE]
[IMAGE]
Modularization is the key to reaping the benefits of Integrated Language Environment (ILE). It is the major factor in cutting development time and increasing programmer productivity -- the more effective the modularization, the more productive the programming staff. But it's important to arm yourself with a reliable method when modularizing your applications.
More Information
[IMAGE]
Modularization is usually intuitive. But, often it is done without much serious thought. For example, many programmers will instinctively try to break up long programs with subroutines but few will attempt to make reusable subroutines (i.e., subroutines that other programs can share and use). However, for the most part, this is not the fault of the programmer. Instead, it is the fault of the old RPG language -- a language without true subroutines (i.e., no parameters and no local variables), and of the old OPM environment, a programming environment without static binding.
ILE, of course, changed all this. Now, the native AS/400-iSeries environment almost demands modularization. Here are some tips to help you take advantage of modularization (note, when talking about "modularization", we refer to breaking up applications into reusable procedures, not necessarily the modules that contain the procedures).
Design and code system-wide functions and procedures
Initial modularization is the process of creating system-wide f...
To continue reading for free, register below or login
To read more you must become a member of Search400.com
unctions and procedures. These are the utility-type procedures that have the potential of being used by any -- and possibly all -- programs. Conversion procedures (e.g., convert to uppercase) and string and numeric manipulation procedures are good examples.
Make sure to design these procedures with the greatest amount of flexibility possible. For example, instead of designing a ToUpper function that accepts only a 50-byte fixed character string, use operational descriptors so the function can accept any length string in any format. Another, quicker, alternative is to use a separate parameter to communicate the length of the string (the new %size built-in RPG function makes it easy to set the parameter in the calling program).
For new systems, start at the beginning of the design process
Modularization should come soon after database design, which is usually the first step in designing a new system (i.e., a group of closely-related applications such as an "inventory control" system or an "order processing / customer service" system). The goal is to construct building blocks that you can quickly piece together to create applications.
For example, normalized databases are a proven way of storing data, however, retrieval of that data often involves reading from many files, sometimes coupled with complicated logic. You may be able to wrap-up this complicated I/O logic into a tidy procedure that many applications can share.
Design for cross-system use
Pay particular attention to how other systems (still talking about a group of related programs) might use a procedure and design the procedure accordingly. Keep other system's requirements (and possible future requirements) in mind when designing the procedure.
For example, applications in the order processing system will possibly use a procedure in the inventory control system that returns the stock on hand for a specified item. In such a case, make sure to take into account the order processing system's requirements (and possible future requirements) when designing and coding that specific inventory control procedure.
-----------------------------------
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years' experience programming for and managing AS/400-iSeries systems.
