The Display Module Usage (DSPMODUSG) command is an ILE tool that helps you to identify which programs were compiled referencing a particular module (modules were formerly known as programs in the Original Program Model). This easy-to-use utility is a must if you are going to use RPG IV.
If you work in an RPG II or RPG III shop and you have not already taken a serious look at RPG IV, it may be time to do so. The enhancements to RPG IV have been announced at a fast and furious pace in the last few years. The IBM development labs in Toronto have done a wonderful job of adding functionality and features to our RPG toolbox, with numerous enhancements still on the horizon. If you have not moved to RPG IV, you may be missing the boat.
The RPG source specifications have changed: There are new data types to use, and there are new op codes to explore. Lowercase source code is now allowed, and longer field names are supported. New control keywords have been added to our file specifications and the new definition specification. New free-form expression support has been added to improve string handling and mathematical formulas. IBM has even provided a conversion tool to take you from RPG III to RPG IV.
But we think IBM left out a couple of things that would be useful. In this article, we will address one of these shortcomings and offer a remedy for the problem. But before we get too carried away, let’s see if we can simply cover what is required in going to RPG IV.
Fish or Cut Bait
With all of the goodies that were added with RPG IV, you will also need to contend with the dreaded Integrated Language Environment (ILE). Frankly, we do not see what the fuss is about.
Like so many other things in life, ILE is what you make of it. If you want to approach the issue like a bull in a china closet, you can convert your code and begin to use all of the many ILE goodies that have been announced in the last several years. You can
explore service programs, activation groups, scoping, and so much more. But you can also take a little more subtle approach and kind of ease into it. You can take advantage of the many enhancements to RPG, without having to get into the more advanced ILE topics.
When we elected to move our shop from RPG III to RPG IV, ILE was the least of our worries. Oh sure, there were a few differences we knew we were going to have to contend with, but we elected to keep the changes pretty minimal.
The basic things you need to know when converting to RPG IV are as follows:
• The size of your RPG source file can no longer be 96. It now needs to be 112. The default name for the RPG IV source file is QRPGLESRC, but we prefer to put all of our source in a source file called SOURCE (pretty imaginative, huh?). Source files are created using the CRTSRCPF (Create Source Physical File) command.
• The CVTRPGSRC (Convert RPG Source) utility provided by IBM automatically converts your RPG III source to RPG IV. It is easy to use, and it provides you with a way to look at the “before” and “after” pictures. You will note that the source type before conversion was RPG, but the converted version is now RPGLE.
• The compile option (14) of PDM will compile an RPGLE source member with the CRTBNDRPG (Create Bound RPG) command, instead of the CRTRPGPGM (Create RPG Program) you are familiar with.
How about that? You now know everything you need to know to convert your code to RPG IV and begin using ILE. That was not so bad, was it?
Let’s talk about a few of the details so that you have a better understanding of the bigger ILE picture.
The source file needs to be a larger size because the specifications have changed. We are not going to get into the many advantages of RPG IV here, but numerous good books on this topic are readily available. When you run the conversion programs, you will see many of the changes take place in the before and after pictures of the source.
The most significant change you will deal with when you convert to RPG IV and ILE is that you compile individual source members into modules, instead of directly into programs. One or more modules are then bound together to make up a program. In the Original Program Model (OPM), we used to skip this step and compile the source members directly into programs. One thing you can do to minimize the trauma associated with going to ILE is to use the CRTBNDRPG command to create both the module and then the program, too. Fortunately, IBM made this the default PDM compile option for RPGLE source types.
Baiting the Hook
The original premise behind ILE was that the environment offered an opportunity to mix and match modules from different environments to create a single program. The idea was that the modules did not need to be from the same applications—or even coded in the same language. In effect, modules would become reusable code that could potentially show up in many different applications. And, for even more flexibility, ILE allows developers to decide when they want to bind modules into programs: either when the program is compiled or when it occurs at runtime (dynamically).
The idea of reusable code is one of the basic tenets of the object-oriented (OO) program model as well as one of the primary objectives of the San Francisco project (in which applications are purchased and then incorporated into other applications as components). But the idea of reusable code is not new (sorry, all of you OO devotees out there). The S/38 was one of the first “object-based” systems that allowed us to write a single program and then call that program from several different applications. The program
Fear Not…
was, for all practical purposes, reusable code. This technology was later brought to the AS/400 and then improved on.
The One That Got Away Was THIS BIG…
ILE was a wonderful way to create a multilanguage environment that can share many reusable modules. Since modules can be bound into programs, the overhead required by the dynamic program call can be eliminated. But there are some downsides too.
The biggest challenge for a software house like us was in the area of maintenance. Because we have hundreds of AS/400 systems to support and maintain, it is of vital importance that we have a clear understanding of how each module fits together when applying program maintenance. Without this critical knowledge, it is conceivable—no, make that likely—that we would not always send all of the required modules when applying program maintenance. You can imagine what a mess we would have if we bound updated modules to copies of old, improperly maintained modules.
This very challenge led us to create the tool we have included in this article. The Display Module Usage (DSPMODUSG) command allows you to see where each module is used in your system. The display output of the DSPMODUSG command may be seen in Figure 1. The output may also be printed, if so desired.
Caught a Whopper
The source code for the DSPMODUSG command is illustrated in Figure 2. The command is compiled so that it will run the MOD001RG program seen in Figure 3 on page 64. The display file for the MOD001RG program is named MOD001DF and is illustrated in Figure 4 on page 65.
The program uses the Create User Space (QUSCRTUS) API to create a user space that the Create Bound List Program (QBNLPGMI) API uses to hold a list of all programs that match the requested search criteria. It then “walks” through the user space, writing a subfile record for each entry found there. The subfile is then either printed or displayed, depending on the PrintorDsp parameter passed from the command.
Supper Time
If ILE has been a deterrent for converting your RPG III shop to an RPG IV shop, it should not continue to be. The entire effect of ILE can be minimized to such a degree that it is hardly even noticed. Your system will run faster (RPG IV programs run significantly faster than OPM programs), and you will have many more RPG tools at your disposal.
If you do elect to take advantage of the ILE , we hope that the tool provided in this article makes your job a little easier.
LATEST COMMENTS
MC Press Online