Guru: Customizing RDi Beyond Preferences

May 3, 2021 Susan Gantner

In my last tip , I covered a few of the preferences that I like to change to customize the way I use RDi. But there are a number of other customizations I use that aren’t implemented via the Preferences dialogs. I’ll continue the customization topic in this tip by covering some of those other options.

Compile-Related Customizations

I’ll start out with a couple of things I like to change related to compiling code. This includes customizing and creating new compile commands and modifying my compile Error List.

I like to modify some of the parameters for the “ordinary” compile commands, such as CRTBNDRPG, CRTRPGMOD, CRTBNDCL, etc. Obvious candidates here include specifying the target library for the program and target release when working in an environment when the production systems are at an older release from my development system. I also prefer to use DebugView(*All) instead of RDi’s default of *Source. (I figure when I’m debugging, I need all the help I can get!)

One parameter that I specify that may be less obvious is Output(*None). In other words, don’t create a spooled file for a compile listing. Compile listings tend to be used 99.9 percent of the time to find compile errors, but that’s what Error List is for! So I see no reason to keep producing spooled files that I’m never going to look at and that I’ll just have to clean up some day. One thing I’ve recently found out is that for some languages, DebugView(*All) and Output(*None) are incompatible. It works for the RPGLE compile commands, but not for CLLE and probably others.

I also create a few special-purpose compile commands. For my own use, I don’t typically need anything all that complex but I have worked with some clients where I needed to compile back to a previous release or to compile a program with adopted authority. When working in those situations, I’ll create special versions of the regular RPG compile commands and give them relevant names such as “CRTBNDRPG Prv Rls” or “CRTBNDRPG Adopt.”

To do any of these things, use the compile menu in RDi and choose “Work With Compile Commands. . .” Choose one of the “normal” commands in the list to change the default parameters (such as Output(*None)). The Prompt button makes it easier. Figure 1 illustrates how to customize an existing command. To create a special-purpose command, choose “New command” from the list, give it a descriptive name (Label), enter the command, such as CRTBNDRPG, and prompt to fill in the parameter values you need.

Figure 1: Work with compile commands.

If your compile needs are a little more complex — perhaps you use a completely different compile command or use a non-standard command to do your compiles — there are a couple of other things you’ll need to know. I’ve covered those (as well as a few more details about some of the things mentioned here) in a two-part series of Guru tips published a few years ago. This tip covering more complex compiles contains a link to the earlier tip as well.

Once you’ve done a compile from RDi, chances are good that at least some of the time you’ll have some compile-time errors to correct. That’s easy, thanks to the RDi Error List view. I like to filter out the messages from the Error List that I don’t intend to do anything about, for example, the 00 level information messages when compiling an RPG program. This may seem trivial. But I find that there’s a big difference between having a completely empty Error List and having one with several 00 messages listed. At a glance, it’s far easier to tell that I have a clean compile.

Filtering out the 00 messages is done using the view menu in the Error List view. See Figure 2 if you’re not sure how to find it. Then choose Show Severity and — at least in the case of RPGLE — turn off (de-select) the Information messages. It will remember that choice for all your future compiles of that member type. While you’re at it, you may also want to take a look at some of the other options on that menu which have to do with how and/or when the errors appear in the source window. Personally, I’m happy with the default values for those, but I know some people who prefer to tweak those options, too.

Figure 2: Filter out information errors.

Customization Using Perspectives

Another way to customize RDi is by changing the standard perspectives. Everyone uses RDi a little differently. Some changes we make are simple things like stretching the size and shape of the views, or perhaps deleting some views that we don’t use. Likewise, you very likely have some views that were opened up and added to your perspectives automatically for you. For example, if you’ve ever debugged a program using Service Entry Points, you likely had a view of that name appear in your Remote System Explorer (a.k.a. RSE) perspective.

Sometimes you may want to make more deliberate changes to your perspectives for a specific purpose. I’ll highlight here as an example some changes that I made to my version of RSE to make using the DDS Designer tool much easier.

I’ll lay the groundwork first for why I felt the need to make these changes. By default, when opening a DSPF or PRTF member type, RDi suggests that you may want to switch to the DDS Design perspective. It makes its suggestion unless or until you eventually click the box that said “Remember my decision.” The DDS Design perspective is very similar to RSE, but some changes were required to allow for the design palette and to provide more space in the properties view.

I have a few issues with the DDS Design perspective, but the biggest one is that it wants me to switch perspective when I open a DSPF but it doesn’t automatically switch it back to RSE when I go back to working on the RPG code that uses that DSPF. Since my DSPFs and PRTFs are always closely aligned with an RPG program, it seems cumbersome to keep manually switching perspectives back and forth depending on which edit tab I’m working with at the moment.

I discovered that I could make a few small changes to my version of the regular RSE perspective that would make it as efficient for working with the DDS designer as for editing RPG code. One obvious change needed is to move the properties view from the tiny box where it appears in the default RSE perspective over to the larger area under the editor, where things like the error list are. This is done by simply dragging the tab and dropping it where I want it. The Remote Scratch Pad view that is normally underneath properties in RSE can either be moved as well or (as in my case) removed if you don’t use it.

The DDS Design perspective includes a palette view. I found that having it there caused problems when using the designer in full-screen. If I don’t have a palette view in my perspective, it works better because the palette attaches itself to the design window. That way when I go into and out of full screen edit mode with the designer, my palette is always there. If you don’t see the palette in your design window, look for a small triangle in the top right margin of the design screen (circled in red in Figure 3). Click on that triangle to open the palette and click it again to close it.

Figure 3: Customized MyRSE perspective. (This gives you a look at what my new customized version of Remote System Explorer looks like.)

Now I have my RSE perspective re-designed slightly, I have only two things left to do.

First, I’ll change the option from the DDS Design preference page “Open associated perspective when editor opens” to “Never.” It is often either set to Prompt or Always, depending on whether you clicked the “Remember my decision” box at some point in the past.

Second, I save my new version of RSE to my own name. That’s done from the RDi Window menu option Perspective > Save Perspective As. . . . I call my new perspective “My RSE.” This becomes the primary perspective I use in RDi from now on. If I ever need to reset my perspective for some reason, I can do that and it will take me back to this last-saved state. If I didn’t give it a new name, it would reset it back to the original Remote System Explorer and I’d have to do this all over again!

I’ll point out one more customization I recommend when using the DDS Designer. Select (click on) the “Draw records transparent” icon, circled in green in Figure 3. That allows you to see multiple formats on the screen at once when designing. Most notably, you can see subfile and subfile control records at the same time. For more of my thoughts about using DDS Designer, take a look at this Guru tip from several years ago on this subject.

This new perspective I just made for DDS Design is just one example of how you can make small changes to make RDi tools work better for your own purposes. I’ve had students ask how they can do full-screen editing and keep the outline view present. Some ask how to keep the RPG indented view present when editing in full-screen. There are other ways, but one simple way to accomplish these tasks is to create a special-purpose perspective with nothing except the editor and the outline (or the indented view) and save it to a name such as “Outline” or “Indentation.” Now they can be available to you at the click of your mouse when you need them. For more details about that subject, you may want to check out this Guru tip.

In the Debug perspective and if you’re running at least RDi V9.6.0.7 I recommend that you modify the maximum length value that you can see in the Monitors view when debugging. (See Figure 4.) To do this right click in the bottom part of the Monitors view and choose Max Length. The default limits you to seeing 10,000 characters. The max we can see as of now is 30,720 so I’d set it somewhere close to that value. You’ll notice that a value 0 sets it to unlimited. However I found that the resulting font size made it impractical to use. While you’re there, I recommend choosing the “wrap text” option as well. Otherwise you’ll spend a lot of time scrolling to see very large values when debugging.

Figure 4: Monitors view in debug perspective.

Before I leave the topic of customizing perspectives, there are a few views that you may not have in your own RDi setup. Here are some recommend views that I find very useful.

If you’re currently using Remote System Explorer or a perspective based roughly on that one, make sure that you still have Outline, Commands Log and Object Table available. Those are part of the default RSE perspective, but they are views that I often find people don’t have, either because they inadvertently closed them somewhere along the line or perhaps even purposely closed them because they weren’t using them. If like me you do a lot of work with RPGLE members, you really should give both Outline and Commands Log another try if you’ve “lost” them.

Object Table is one that many people never used so it’s not surprising that it disappeared over time. However, it got a new lease on life in the last couple of years. I encourage you to take a look at the new, improved Object Table. I’ve written a few tips in the past talking about my new-found love of this view. You can check out this Guru tip and/or this one for all the ways you can use Object Table now. I’ve found that many people seem to think that Object Table is only associated with the PDM Perspective, but that is not true at all. I use Object Table daily in conjunction with Remote Systems in my own RSE perspective.

In addition, I’d suggest you take a look at a couple of views that aren’t in the RSE perspective by default so you may have never known about them. Take a look at the new Library List view (I wrote about that here) and the Snippets view (check out this tip).

There are one or two more customizations that I find helpful, but I think I’ll save those for another tip on another day. Feel free to share any ways that you like to customize RDi. I’m always looking to learn more ways to make RDi even better.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search