Guru Classic: More iSphere Goodies

March 4, 2020 Susan Gantner

This Guru Classic tip is my third in a series exploring the iSphere RDi plug-in. In this tip I’ll cover two additional ways in which iSphere expands the RDi toolset. There are a few details that I’ve updated in this new version of the tip due to updates in either RDi or the iSphere tool itself. Plus I have added an additional tip based on how I’ve seen one of these features utilized.

Binding Directory Editor

I’ve long been baffled at the lack of support in RDi for binding directories; it seems like something modern developers certainly use. In the past, I created RDi user actions that simply prompted CRTBNDDIR (Create Binding Directory) and ADDBNDDIRE (Add Binding Directory Entry). But when it came to actually looking at the existing entries in a binding directory already, I used the green screen commands. No more! Now I use the iSphere Binding Directory Editor.

Figure 1: The iSphere binding directory editor

As you can see in Figure 1, it’s not exactly rocket science. In the Remote Systems (a.k.a. RSE) view — or, if you prefer you can use the Object Table view — right-click on a Binding Directory and take the iSphere Binding Directory Editor option to bring up the dialog. In my sample, I right-clicked on an entry and took the Change option, which brought up the inner dialog box. Other options for entries include Copy, Delete, and Display for existing entries, and New to add a new entry to the Binding Directory. Note also the up and down buttons to change the sequence of an entry.

I still use my user action to create a new binding directory, but that’s not a problem because I don’t do it that often and it’s pretty straightforward. Editing existing binding directory entries is much nicer now thanks to iSphere.

Task Tags

I should say up front that I have had a bit of a love/hate relationship with Task Tags (a.k.a. LPEX Task Tags). I like the idea but some of the implementation details take some getting used to. To be fair I should point out that the folks who created iSphere are not responsible for the implementation details. iSphere didn’t invent Task Tags, it simply enabled the support that already existed for the Java editor for other source member types.

To lay a foundation, let me first explain about Eclipse Tasks generically (as compared with the specific Task Tag flavor) as enabled in RDi right out of the box, even without iSphere installed. At any time, I can create a task associated with a line of code in a source member. To do that, I right-click in the far left margin in the editor, to the left even of the sequence number, and choose Add Task. (See Figure 2.)

Figure 2: Adding a task

After doing that, a dialog pops up that allows me to put in any comment related to that task that I like, such as: “Externalize this proto after testing” or “Subfile displayed here.” If you don’t put in your own comment, it will simply copy the line of code as the task text, which is ugly and rarely very useful. The task will then appear in your Tasks view, such as the one you can see in the Figure 3. If you don’t have a Tasks view in your perspective (it’s typically placed below the editor in the same area with the Error List and Commands Log), you can bring it in using the Show View > Other. . . option from the Window menu.

I use ordinary Tasks like this regularly, either to remind me to do things I may forget to do or as a sort of bookmark to a section of code that I find myself needing to return to often. Later on, a double-click on a task positions my cursor to the line of code, opening the source member in the editor if necessary. Tasks are persistent and will remain until I remove them. When I don’t need these tasks any more, I can clean them up with a delete via right-click menu or I mark them as complete (click the check box) and later delete all the completed tasks via a right click menu option. I’m forgetful sometimes, and Tasks help me stay focused and remember what I need to do. Tasks stay around even after you have closed the source members they are associated with.

The special Task Tags provided by iSphere enable a different kind of task, one that is created automatically when I put a specially marked comment into the code. The special marks are actually keywords—the default keywords are FIXME and TODO. So a task would automatically be created in my Tasks view for that line of code if I were to put a comment line in my program such as: “// ToDo Externalize this proto after testing.” Note that you must save the source member after adding the task-tagged comment before the task appears. Likewise, once you remove the comment line (or its task tag keyword) from the source and save the source, the task will be automatically deleted. Figure 3 shows some ordinary tasks and some of the Task-Tag-created tasks, which have Type=LPEX Task vs Type=Task.

Figure 3: The Tasks view

The Task Tags keywords may be enabled/disabled via a preference under the iSphere preferences (iSphere > LPEX Task Tags) and you can configure what source types they work with. You may also configure which Tags are the magic words to create tasks when they appear in a comment line. The ones set up by default are FIXME and TODO. You may remove those and/or add your own on the iSphere preferences page — just click on the “Configure Task Tags” link near the top, then ignore the bit on the resulting dialog that seems to indicate that they will only work in Java comments!

So, what’s not to like? I use tasks a lot, and using comments initially seemed a nicer way to create them. I was bothered at first by the fact that I had to remember to save the source before the task appeared, but that’s not a big deal (especially using the shortcut Ctrl+S). Then I noticed that I didn’t have the same level of control over this type of task in the Tasks view. I couldn’t delete an individual LPEX task or even mark it as complete. This probably makes sense given the nature of them, but it required that I rethink how I interacted with these tasks. Still, not a major issue.

Then I opened up a few source members where another developer had put in his own “ToDo” Task Tags in comments. Even when I only opened it to browse, those Task Tags created tasks in my view. It took me a while to realize this was happening and by the time I noticed, I now had dozens of tasks that I didn’t want in my Tasks view, cluttering my view and making it difficult to use my own tasks. Remember that I can’t delete or mark them as completed as I could my ordinary tasks. Initially I thought that the only way I’d ever get rid of these tasks was to remove the task tag keywords in the comments put there by the other developer — not a very nice thing to do!

I eventually woke up to the fact that I could (and should) simply configure my own Task Tags — creating task tag keywords that I wanted to use for my own work and removing the default TODO and FIXME ones. Even after reconfiguring my preference, it seemed that I needed to re-open each source member that had caused them to appear in order to get them to disappear.

An enhancement to this support now allows all LPEX Tasks for a specific source member to be deleted from your Tasks view. If you right click on a task and choose “Delete LPEX task tags” all the tasks in your view for that source member will be deleted. Beware, however, that opening up that source member again in the future will bring them all back again! So this delete feature is best used for members that don’t exist anymore on the system or for deleting tasks after you have configured your own preference to remove the default keywords.

That’s why I have now removed the default Task Tags in my preferences (FIXME and TODO) and I have created my own unique Task Tags for my own use. Truth be told, I still primarily rely on the ordinary tasks I used before more than these LPEX Task Tags enabled by iSphere.

But since at least one of my fellow developers clearly finds them very useful, I thought it was a feature I should share with you so that you can give them a try and make up your own mind.

I have heard from one shop that makes good use of these. When a junior developer is tasked with making changes to an unfamiliar source, a senior developer gives some guidance about where in the source changes should be made by adding comments containing the junior developer’s name. The junior then configures their task tag preferences to include their own name. Now, a list of tasks will automatically appear to help guide that person when they open the source member. They can simply double click on a task to be positioned in the source the right spot to begin their work.

I’ll cover more iSphere features in later tips, so stay tuned.

Susan Gantner, an IBM Champion and co-author of the popular Redbook, Who Knew You Could Do That with RPG IV, is one of the top speakers/writers/trainers on IBM i development topics. She is a partner at Partner400 and System i Developer, and she hosts the RPG & DB2 Summit twice per year with partners Jon Paris and Paul Tuohy.

RELATED STORIES

Guru Classic: Looking For Stuff With iSphere

Guru Classic: iSphere Plug-in Expands RSE/RDi Toolset

Guru Classic: My Favorite Keyboard Shortcuts for RSE/RDi

Guru Classic: Giving RDi a Split Personality

Guru: Ready or Not! RDi V9.6 (Series of 5 tips)

Guru: RDi V9.6, Part 6 – The New Object Table Gets Even Better