Guru: RDi V9.6, Part 10 – Debugger Enhancements

November 16, 2020 Susan Gantner

Here I go again – more enhancements to talk about that have come about in RDi V9.6. This time, it’s the debugger that has been enhanced. The 9.6.0.7 fix pack included some new goodies for the debugger.

Both of the enhanced features were popular Requests for Enhancement (RFEs) — the ability to display very large variable values and the addition of a condition to Service Entry Points (SEPs). These are further proof that the RFE process works. If you haven’t visited the RFE site to vote for your favorite suggested features for RDi, do it now. . . or maybe wait until after you finish reading this tip!

Displaying Large Values

If you sometimes work with very large variables in your RPG programs — perhaps generating or processing XML or JSON documents, for example — you have very likely bumped into the limitations of RDi’s Monitors view to look at the current contents of a variable. The limit on the maximum length value we can view has gone from 4096 characters to 30,720 characters. Hopefully that will go a long way to helping debug some of those programs with large fields.

There are a few things you need to know about how to put this enhanced feature to work. First, your host IBM i system must be at V7.3 or later. Second, you’ll need to have the following PTFs installed for product 5770SS1:

V7R3M0 PTF SI71302
V7R4M0 PTF SI71314

Figure 1: Monitors view for displaying large values.

The next thing you need to do is to enable your RDi Monitors view to show the new larger sizes. In Figure 1 you can see that I have selected VERYBIGVAR and I can see the value in the bottom section of the view. However, after installing the required PTF on my system, I found that I could see more than 4,096 but it still wouldn’t show me more than 10,000 characters. It turns out that there is a maximum displayable length in that large display area of Monitors that is set to 10,000 by default. When you right-click in the display area indicated in Figure 1, you’ll get a context menu, which allows you to set the maximum viewable length.

Figure 2 shows the dialog box. Don’t be misled but the “0 = unlimited” statement. The maximum size value you can see here is 30,720 even if you set it to 0. I decided to set mine to 35,000. If we ever get a larger limit, I’ll have to remember to come back here and change it. As an experiment I put in a very large value and it reacted by making the font tiny, so I decided to stick close to the actual limit.

Figure 2: Set Max Length dialog.

In a way, I was happy that I was forced to find out how to set that maximum length because in the same context menu with the max length option, I also found the ability to turn on text wrapping, which made it much easier to view the large values. Without that option, I was doing a lot of scrolling to see the value in a single, very long line!

Even with wrapped text, that little box is pretty small to view large values effectively. But, of course, just as with any other RDi view, you can double click on the Monitors tab (or use the maximize button) to see it in full screen. Figure 3 below shows a format that makes it much easier to see larger values. For my testing, I engineered the values in the large variable so that I could tell roughly what character I was looking at — I put a number for the current position into every 50th character. As it turns out, though, the offset position from the start of the variable is displayed at the bottom of the debug perspective screen anyway, as shown in Figure 3. My cursor position doesn’t show up in the screen shot, but the red arrow points to where my cursor was (at position 7000), which is also reflected by RDi in the figure at the bottom of the screen.

Figure 3: Full screen Monitors view.

While variable values can normally be changed during a debug session, these larger variables are an exception to that. Only variables that are 4,096 or less in length can be updated in Monitors.

Conditional Service Entry Points

Debugging with Service Entry Points (SEPs) can simplify starting an RDi debug session. Using SEPs the IBM i host will monitor for a specific user profile starting a specific program. When that happens in any job on the system, the SEP process will stop the program, putting it into debug mode and then notify the developer who set the SEP by going into debug mode on the program in RDi. If you want to learn more about SEPs, take a look at this earlier tip Guru: Three Little Words That Simplify Debugging.

In many situations SEPs work well. But sometimes, particularly in server jobs, such as web server or database server jobs, a generic user profile may be used to call the programs. While you can set an SEP using that generic profile, when anyone runs the code, the SEP will kick in and stop each job and notify the developer that it’s ready for debug. It could start up many debug sessions, not just the single one that you intended to debug.

To provide a mechanism to make SEPs trigger in more specific situations, 9.6.0.7 has added an optional condition to SEPs. It works in a very similar manner to conditional breakpoints. Since SEPs get control only at the beginning of a program or procedure (hence “entry point” in the name) the condition must be true before the program or procedure P starts to run. Therefore the condition will most often be based on the values of 1 or more parameters being passed to the program or procedure.

For example, I could set an SEP on a program and condition it on CustNo = 1234, where CustNo is an input parameter to the program. Then when the user profile specified in the SEP calls the program, the system will first check the value of CustNo. If it is 1234, the SEP will trigger and the job and program go into debug mode. If CustNo has any other value at the start of the program, the SEP ignores it.

You can set the condition when starting the SEP from Remote Systems via a new prompt option or you can simply set an unconditioned SEP as you normally would and then modify the SEP (via the context menu) to enter a condition after it appears in the IBM i Service Entry Points view. After the program has been debugged with one condition, it’s possible to change the condition to trigger on a different value — you don’t need to set a new SEP. Figure 4 shows the service entry point view with a condition specified.

Figure 4: Conditional Service Entry Point.

As with the monitor enhancement above, this feature is only available when running IBM i 7.3 or later and the following PTFs are required to enable it:

V7R3 PTF SI70844
V7R4 PTF SI70888

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search