An RSE Wish List
What we'd add to one of our favorite Rational products
A few months ago, we covered some RPG enhancements that are tops on our wish list and invited you to add to the list via our blog. Several people entered into the discussion and together we ended up with a great RPG Wish List. This month, we thought we’d begin a similar discussion on one of our other favorite IBM Rational products—RSE (aka Remote System Explorer, RDi, RDP, RD Power, WDSC, etc.)
We love so many things about our favorite code editing toolset, but nothing’s perfect. So here are a few of the things on our list of “wouldn’t it be nice if...” for the RSE toolset.
- “Tidy up” the indentation of existing /Free format logic
RSE already has a “Convert to /Free form” option to convert fixed format logic to /Free form logic, complete with logical indentation. So it doesn’t seem like it would be rocket science to take some logic that’s already /Free form and reformat it with appropriate indentation.
- More granularity on RPG enter key preferences
Many times the “Repeat previous spec type” default preference is not desirable, especially if, like us, you like to leave completely blank lines in your source. However, if you turn off that default preference, then you also end up turning off many other preferences that are tied to it, such as automatic indent and automatic closure of control block. Admittedly, when coding in /Free format, the “repeat previous...” option isn’t nearly as much of an irritant as in the fixed format logic days, but it’d still be nice if we had the option to keep other features in the editor while still keying in our own spec type entries when we want.
- An easier way to comment (and un-comment) a block of RPG code
It seems many people who hang out on the WDSC-L list on midrange.com have come up with their own favorite techniques for doing this but it would be great if the editor would simply have an option to comment or un-comment a selected block of code on the context (right-click) menu, like the one in the RSE editor for COBOL.
- Something to help with outdated cached file descriptions
One of the most common issues that confounds new (and sometimes experienced) users of RSE is confusion caused by cached information that’s “stale.” The scenario is this: You’re working on a program you’ve worked with before and, thanks to your previously cached file descriptions, your Outline View is already populated when you open the member. However, one of the fields in a file either doesn’t show up or has the wrong definition when compared to the current field descriptions. The reason is because the Outline View (and the source verifier and content assist lists) work from the locally cached file descriptions to improve the speed. It can get very frustrating and confusing however, when the cached descriptions are not current.
It’s not that difficult to “fix” the outdated cache problem currently—you can cache the file description from the context menu in RSE or you can Verify (Prompt), and choose the “Refresh cache” option. However, both options require that you know that you have an outdated cache issue and the first option further requires that you know which files are affected.
Closely related to this problem is that using either option seems to re-cache all the file descriptions even if the information hasn’t actually changed—at least we’re assuming it re-caches everything because it takes so long. It would be much less painful if it would check the file format level indicator to determine whether the currently cached information is OK and save time by ignoring the refresh request for those files.
Also, since many RSE users don’t use the Verify function (we’re not sure why—we love it!) it’d be great to have an option to refresh cached file descriptions when refreshing the Outline View since nearly everyone loves Outline. We don’t want the cache refresh to happen all the time on an Outline refresh because it would make it too slow, especially if done without the intelligence to check whether refresh is needed, as mentioned above. So to do this we’d probably need a second type of refresh button or a context menu or view menu option to implement this.
Search our new 2013 Buyer's Guide.
E-Newsletter | Namespace support makes the opcode a viable option
E-Newsletter | The finer points of OpenRPGUI, Part 1