Technical Tips
RSE and RDi
The following tips were written over different versions of the Rational Developer for i
toolset (aka RDi, RDP or even WDSC.) The basic information applies to most versions,
but don't be surprised if your release has slightly different wording or options. Just
email us if you have questions about the applicability of these tips to your specific
version. (P.S. Please accept any use of old nomenclature, such as iSeries, in its
historical context.)
When working in RSE, sooner or later you will want to work with a block of code. When you do, remember Alt+L!
There are many ways to select a block of code. You can drag your mouse over the block or hold down the Shift key and use the cursor arrow down key to select the lines for the block. The one I've found most useful, however, is the Alt+L shortcut key.
Alt+L - used once - selects the current line in the editor. I find this way to select a line for copy/paste better because it always selects the entire line, not just a portion of it. When pasting a portion of a line in RPG - particularly fixed-format RPG - it can be tricky to position the cursor before the paste so that the columns line up correctly. Using Alt+L followed by Ctrl+C (copy), I can then move to the line where I want to paste it, use the Home key to ensure I'm in the first column of that line and then paste (Ctrl+V). Note the RDi editor will insert the pasted line before the line where you positioned - no need to insert a blank line!
Alt+L can be even handier when selecting a block of code for copy/ paste. Simply use Alt+L on the first line and then Alt+L again on the last line of the block you wish to select. As before, use Ctrl+C, Homeand Ctrl+V to insert the lines. Since the lines will be inserted, there's no need to guesstimate the number of blank lines needed before the paste.
Why don't I just use the SEU line commands C/CC and A or B? I often do. But it's important to know both ways because the line command option is available only within a single source member. To copy a block of code from one source member to another in RSE, I must use copy/paste.
Want a way to comment a lot of RPG code very quickly? Select a block using Alt+L (or any other method) and then use the Ctrl+/ shortcut key to comment out the block of code. The editor knows if the appropriate comment method is * or //. And you can customize whether it overlays or shifts the rest of the code by using preferences for the ILE RPG parser. The Ctrl+\ shortcut performs the reverse action, i.e. it un-comments the selected block of code.
Both Ctrl+/ (comment) and Ctrl+\ (uncomment) work on individual lines of code as well. In that case it's not necessary to select the line - it will just affect the line your cursor is on.
Have you ever needed to shift a block of code over - maybe because copy/paste messed up the alignment or because you added another level of nesting in free format logic and you want to keep the correct indentation? Give this a try.
Select the code block to be shifted using Alt+L at the beginning and end of the block. Then use Alt+F8 to shift the entire block one character to the right. Repeat as needed. Alt+F7 shifts the block left.
Much more fun than using the old RR and LL line commands!
RDi V9.5 Update: If you're shifting lines to correct indentation in free-format RPG code, give the new Format feature a try - Ctrl+Shift+F or Format under the source menu option - for a selected block, or for the entire source if nothing is selected.
If you find yourself struggling with how to use the debugger in RDi (or WDSC and RDP), three little words might help - Service Entry Points.
If you have not yet experienced the joys of debugging with Service Entry Points, try it today. In the Remote Systems view (RSE), choose a program object that you need to debug. Right click on the object and select Debug (Service Entry) > Set Service Entry Point.
It may take a few seconds, but you will see a confirmation message, and the Service Entry Points view appears in the workbench. Your program name appears in the list of Service Entry Points. The default settings include *All modules in the program, *All procedures in the program and your User ID. It may look something like this.
Setting that Service Entry Point says that when this program is invoked by your user profile, the IBM i host debugger is to do what is effectively a combination of STRSRVJOB and STRDBG on it, kicking off your debug session. Here is what will happen:
- the job and program is put into debug mode
- the debugger waits for your interaction before the first executable statement
- RDi will switch to the debug perspective if necessary
- the source for the program opens in the editor if it's not already open
After setting the SEP, go to another job (i.e. an emulation session) and call the program to try it out. It may take a moment for the debug session to start but when it does, you are ready to add any breakpoints you may need, set up fields to monitor values as you step through the program, issue a "Run to location" from a specific statement in the program or anything else you may do in an RDi debug session.
That's a pretty easy way to start a debug session. The best part is that it doesn't matter if I want to run the program from an interactive session or submit it to batch. Even better, if this program were invoked in some "non-traditional" way, such as in a web or database server job or a remote procedure call, I don't need to be concerned about figuring out what job needs to be debugged (or "serviced"). I can simply wait for the program to be invoked by my user profile wherever that is and it will go into debug mode for me.
Of course, you are not limited to debugging only programs that you personally call. You can right click on the SEP in the list and select "Modify" to change the user profile or specify which module(s) and procedure(s) you want to debug. From the right click menu, you can also remove or temporarily disable a SEP. Another useful option here is to refresh the SEP, which you need to do any time the program is recompiled.
Hopefully these three little words will make your debugging easier. There's more to SEPs, so keep exploring!
RSE is great "right out of the box," but there are many preferences we like to set to tweak it to work even better. Since we spend a lot of time editing RPG code, we thought we'd discuss some of own favorite preference options specifically geared toward editing RPG IV source. Like our keyboard shortcuts, this tip is equally applicable to the RSE editor in RDi or WDSC.
Here's our favorite way to get to the preference page we need. Take the Preferences... option from the Windows pull down menu in RSE. In the entry box at the top left of the resulting dialog page, key in "rpg" to find the relevant preferences. Select from the resulting list under Parsers (i5/OS in RDi or iSeries in WDSC) ILE RPG . This is illustrated in the screen shot, which shows the default preferences for editing RPG code.
Our favorite preferences here are related to Enter key behavior and User defined tabs. When maintaining existing code, especially, the "Automatic closure of control block" feature seems to get in the way, so we typically like to turn that off. We often also turn off "Repeat previous specification type" as well. Now pressing Enter in RPG will simply insert a blank line and position the cursor there.
The ability to set your own tab stops in the RPG editor is a great time saver. Simply check the "User defined tabs" box and then select "C: Calculation" to get an idea of what we mean. To customize the tab positions, simply change the positions of and/or remove the tab markers ("^" characters).
For the standard C spec, for example, we remove the tab stops for the level break and conditioning indicators as well as for Factor 1. We rarely use Factor 1, so it saves many keystrokes to eliminate all those. We also always remove the Len and Hi, Lo and Eq tab stops because they are just so RPG/400!
Answer: Navigate your way to the ILE RPG preferences under parsers (see earlier tip on customizing your RPG editor for details.) Select the "User Defined Tabs" check box. Then select the Definition spec. As with the C spec, each tab position is marked by a ^ symbol (aka a "hat" or "caret" to most of us). Now you can set up your own custom tabs by positioning the ^s in the right spots.
The image below shows what we like to do with our D spec tabs. We'll explain the reasons why we like these settings.
- The first tab stop after the "D" is at the second character in the
name area. Just because the RPG IV language doesn't require that we
leave a blank between the D and the field name is no reason why we
should code it that way. If we do, then the variable names look
really horrible because they all start with D! (For example DcustNum,
DdiscountCode, Daddress, etc.) So we always start the name in the
second position.
- You may want to keep the tab position in the "Ds" position for coding
your DS, S, PR or PI lines. We find that we spend more time defining
fields within Data Structures or parameters within prototypes, so our
next tab stop is at field length. Since most field lengths will be
either 1 or 2 digits, the tab stop is at the second to last position
to minimize spacing. In this case, when defining a Stand-alone variable
or a DS or PR, we simply use the mouse to position the cursor.
- Our next stop is at the second position of the decimal places area
(when was the last time you defined a field with more than 9 decimals?)
- The keywords area is next, followed by Comments - although we rarely
use that area, preferring to use line comments instead.
Once the changes have been made all that remains is to push the "Apply" button and you are done. When you return to your edit window the new tabs will be immediately in force.
Answer: Since the only specific column requirement for /Free specs is that your code be between positions 8 and 80, the primary tab stops that are needed here are to get to column 8 (or whatever column you prefer to use as your leftmost column) and thereafter at every n number of columns, based on how far you want to indent your nested logic.
To do this, navigate your way to the ILE RPG preferences under parsers (see earlier tip on customizing your RPG editor for details.) Select the "User Defined Tabs" check box. Then select the Calculation, Free-form spec from the pull down menu.
For some reason, the default settings seem to be at column 6 (which doesn't seem logical, since nothing can go in this column in /Free format) and at column 8 (the first valid column for /Free format logic) and then every 2 columns after that (note the "And every" box below the columnar tab stops. We prefer to indent our logic a little more than 2 columns, so we like to change this to 3. You would, of course, choose the number that you prefer to use for your logic indentation.
Press "Apply" and go back to the editor to use your new tab stops.
Answer: The tip above talked about how to set tabs when you want to do your indentation using the tab key. However, there is also a setting in the preferences for Automatic indent. By default, this is turned on. You should note that if you chose to de-select "Repeat previous spec type" then the option to use automatic indentation in /Free logic is disabled, along with many other options. See the tip below about "why don't I have the option for automatic indentation available?" for more details on this idiosyncrasy.
Automatic indentation impacts /Free form logic that is coded within a code block - that is, logic between If and EndIf or DoW and EndDo, for example. If automatic indentation is turned on, then after coding the beginning of a block (e.g., an If statement) the cursor will be positioned on the next line at a location indented the appropriate number of characters to the right of the If. The "appropriate number" is 2 by default, but you can change that by using the Blanks box to the right side of this preference.
Answer: Automatic closure of control block means that when you code a statement that requires an End operation (think If, Do, For, etc.) the editor will automatically insert a blank line followed by another line with the appropriate type of End operation (e.g., EndIf, EndDo, etc.). It then positions the cursor at the appropriate spot in the blank line for you to code the logic for the block.
When writing new code, we also find the automatic closure of control block useful, but we find when maintaining code, it tends to get in the way. You can make up your mind whether you like this preference turned on or off. If you decide to keep it on, then you should also choose which flavor of Endxx operation you want. The options have to do with how much, if any, of the Endxx operation should be capitalized. The default is to put it in all caps. But you may choose from the pull down menu which Style of end operation you prefer. Note that the horrible old-RPG/400-style of simply "END" with no xx on the end is not available. Hurray!
Note that you should pay attention to where you want your cursor positioned on that blank line when using this feature. If you're coding in /Free form, then you probably want to make sure that Automatic indent is also selected (which it is by default). If you are not coding /Free form logic, you may want to also turn on "Set C specification cursor position" and position it to the OpCode column (not the default). Otherwise, the cursor is positioned in column 7 — a place you almost certainly don't want!
Answer: If you choose to de-select "Repeat previous spec type" then the option to use many other features is disabled. Disabling the next 4 options makes sense, but it doesn't seem logical to us that choosing to not repeat the previous spec type should turn off automatic indentation in /Free form or automatic closure of control block, but it does. So if you code in both /Free form and in fixed form, you'll have to put up with repeating the previous spec type in your fixed form logic (a feature we prefer to turn off normally) if you want the other 2 features active. If you code only in /Free form, then the Repeat previous spec type option doesn't really have any impact in the logic part of the program.
We would like to introduce you to our favorite RSE feature ... The Outline view!
The Outline view gives you a complete overview of your program. It provides details of every field, file, record format, prototype, subroutine and subprocedure in your program. All fields are listed, including their definitions as shown in the screen shot below.
The numbers beneath the field name identify the lines where the item in question is referenced. References marked with an (M) identify the lines in the logic where the field is modified. Even better is the fact that if you click on an item in the list (as we have done in the example) the editor is instantly positioned on the relevant code.
For more detail on this fantastic feature, check out the answers to the question below.
Answer: If you are editing an RPGLE
source member, the text in your Outline view probably says "Press Refresh
to update view". Of course, that begs the question "What's Refresh?" The
Refresh button looks like 2 small yellow arrows chasing each other in a
circle.
In the Outline view it appears near the upper right hand corner of the view. Pressing this button will populate your Outline view. You'll want to remember this button because you'll also need to use it after you have made changes to the source member to refresh the information in the Outline view.
If you are editing a DDS source member, the Outline view is populated automatically. You need only to expand the + sign to see the record(s) and fields. If you are editing a CLP member or an RPG member (not RPGLE) then you will only see labels (in CL) and subroutines (in RPG). For COBOL source members, the Outline view contains some (not all levels) of your data definitions and your paragraph names. Clearly, Outline view is most useful for the RPGLE language.
Stay Informed
To stay informed of future events, free downloads, and more,
subscribe to our mailing list.
We're here to help you keep your systems strong and vital to your organization.