Let’s finish the debug views discussion started in the previous TechTip and learn how to choose the right debug view for you.
In the previous TechTip, I discussed the *STMT, *SOURCE, and *COPY debug view keywords. Let’s continue that discussion now. The next keyword on our list, in terms of the debug information provided (and the object size), is *LIST, shown in Figure 1.
This view enables source-level debugging with an important difference between the two source views: Instead of maintaining a reference to the source member, the listing view causes the actual source text to be copied into the object. This means that, unlike the *SOURCE and *COPY views, the *LIST view has no dependence on the source member. You can change, rename, move, or even delete the source, and you’ll still be able to perform source-level debugging.
Figure 1: The original source-file line numbers displayed in a Display Module screen of a module compiled with DBGVIEW(*LIST)
When you specify the listing view, you control whether the view contains additional information, such as copy member information or expanded DDS information, for instance, using the OPTION parameter on the creation commands. OPTION(*SHOWCPY) includes copy member information, and OPTION(*EXPDDS) includes expanded DDS information. Figure 1, along with Figures 2 and 3, show what a module compiled with DBGVIEW(*LIST) and OPTION(*SHOWCPY*EXPDDS*SRCSTMT*DEBUGIO) looks like in debug mode.
Figure 2: The expanded copy member (prototype definitions, in this case) in a Display Module screen of a module compiled with DBGVIEW(*LIST)
As you can see in Figure 2, when OPTION(*SHOWCPY) is specified at compile time, the copy members are copied into the module as part of the source presented at debug time. Notice how the original source-line statement numbers restart and have a plus sign (+) suffix for the expanded copy member lines. By pressing Page Down on the Display Module screen in Figure 2, the end of the expanded copy member is shown, and the regular source code—both line numbers and actual code—resumes, as shown in Figure 3.
Figure 3: The expanded copy source and regular module source in a Display Module screen of a module compiled with DBGVIEW(*LIST)
I won’t detail each of OPTION’s possible keyword here; please refer to IBM’s ILE RPG Programmer’s Guide, Appendix D - Compiler Listings for more information.
I intentionally saved the two ends of the keyword spectrum for last: *ALL gives you the “full package,” allowing you to choose which view you want to use at debug time, while *NONE strips the program of debug information.
Choosing the Right View for You
Now that you’re familiar with the different options available, let’s look at some practical issues. Two basic considerations apply when selecting a debug view: object size and the level of debug information. I’ve mentioned that as the level of debug information increases so does the object size. Because of this, you might be tempted to opt for a debug view that has a minimal impact on object size. Don’t be too hasty, however, in making object size your primary consideration. Disk is not prohibitively expensive, and the level of debug information available is the most relevant factor of the two. You want the biggest bang for your debugging buck, and source-level debugging provides that bang.
My experience tells me that the *LIST view provides the best functionality; the increased object size is simply not relevant. This view gives you source-level debugging, and because the source is stored with the object, you’ll always have the source from which the module was originally created. Additionally, you can actually retrieve the source from the object! This ability not only guarantees an exact match between your source and the object, but also gives you a way to recover from deleted source members.
As I said earlier, you can also use the new debugger for OPM programs, so everything you read about the Create RPG Module (CRTRPGMOD) command is also applicable to Create Bound RPG Program (CRTBNDRPG). This means that you can use the ILE debugger to debug OPM RPG and CL programs! I’ll explain how later in this subseries.
Protect Proprietary Souce Code - Coming Up!
Next month’s TechTip will provide information about a very nice feature that IBM introduced with the one of the latest Technology Refresh “packages”: a way to protect your intellectual property (read: your proprietary source code) by encrypting your debug views!