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!
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online