Rational Developer for i (RDi) has many powerful views, and the view you choose depends on how you use the tool.

Rational Developer for i (RDi), IBM's integrated development environment (IDE) for the IBM i, provides advanced development capabilities that easily surpass those we grew up with in the green-screen days of SEU and SDA. Yes, I can still write code using those tools, but RDi makes it so much easier. To me, just having color-coded source with more than 80 characters and 24 lines is enough to move off the green-screen. Unfortunately, the shift from green-screen to graphical can be jarring. And to their credit, IBM continues to make the RDi experience as familiar and comfortable as possible, and the Object Table View is one of the ways they've done that.

Making RDi Your Own

I have used RDi since it was known as WebSphere Development Studio client, or WDSc (IBM does seem to love mixed-case abbreviations). RDi is a powerful tool, and the fact that it's built on the Eclipse platform means that it's also very flexible and you can configure it as you need to best match your working style. In the past, I've written about how I lay out the IDE; here's a quick view:

Figure 1: A 30,000-foot view of my Rational editing perspective

I know you can't see a lot of detail in Figure 1, but that's okay. It's really just meant to show how my work area is laid out. RDi inherits the concept of a "perspective" from Eclipse; this is my editing perspective. Generally speaking, I have a very large editing area (with two independent windows), a navigation area on the right, and a status area on the bottom. Although it looks quite a bit different than the stock editing perspective provided by IBM (called the Remote Systems View) at first glance, it's mostly just a rearranged version. I'm not going to spend a lot of time on the perspective; I want to move directly to the navigation pane.

The Explorer Views

Notice that I refer to "views" plural in this section. That's because I want to demonstrate the relationship between the Remote Systems View and the Package Explorer View that it greatly resembles. Remember, Eclipse began life as an IDE written in Java, so its accent, if you will, is always going to be somewhat Java-centric. This is nowhere more apparent than when you compare the Java-oriented Package Explorer View and the IBM i version, the Remote Systems View.

Actually, that's one of the really cool things about RDi: I can use it to develop hybrid Java-ILE applications. Way back in the previous millennium, I wrote a product called CPYSPLFPDF. It's still in use today, even though much (but not all!) of its functionality has since been superseded by features in the base IBM i operating system. Anyway, I originally wrote it as a proof of concept for combining ILE with open-source Java; the ILE part of the product handles all the spooled file management, while the Java portion uses an open-source package called Etymon PJ/PJX to generate the PDF file. And in RDi, I can edit both. Let me start with the Java side:

 

Figure 2: The Java-based Package Explorer View is tied directly to Java's hierarchies.

The Package Explorer shown in Figure 2 allows you to drill through your Java environment. Since Java is very hierarchical in nature, that typically means folders within folders and lots of drilling in. This is definitely not what we usually think of in the IBM i world of libraries and objects, but it's the norm in most other environments, whether they be Windows or UNIX. RDi has to deal with another hierarchical system on the IBM i: the Integrated File System or IFS. Since the IFS supports the many levels of nested subfolders that characterize a hierarchical system, it also requires a tree view. Because of that, any part of RDi that was going to allow access to the IFS had to be designed with a tree as its primary structure. Here's my IFS:

Figure 3: Here we see the highest level of the IFS of my machine.

You'll see regular folders, and you may also notice QSYS.LIB, which is the folder that contains all the traditional QSYS objects. But the tree is required because of the folder nature of the IFS, which is like any Windows or Linux file system. For example, here's the Remote System View of my machine as I dig into an ancient set of ASFTomcat directories.

Figure 4: This is how the Remote System View handles the hierarchical nature of the non-QSYS part of the machine.

I picked this one because it has a pretty deeply nested set of folders, as you can see. The only UI element that fits this structure is a tree (and even then it's not exactly elegant). But it gets even more clunky when we have to dig into the QSYS libraries.

IDEs Try to Be All Things to All Users

While programmers can ignore the dual nature of the system, IDEs such as RDi don't have that luxury, especially the part of the tool that allows you to navigate the server. It comes down to the interface; the only comprehensive way to show a nested folder structure is with a tree. However, trees and QSYS don't really work well together.

Figure 5: The Remote Systems View tries to bridge the gap between QSYS and folders.

The Remote Systems View provides access to all of your traditional QSYS objects, but does it in a hierarchical format by using a tree view. In Figure 5, the member CSP000 in file QMODSRC in library PBDCSPDEV is highlighted. To get there, I expanded the PBDCSPDEV filter, and then I expanded the QMODSRC file.

This can take some getting used to. It's really not something that's specific to or invented by RDi; you'll see a very similar thing if you use WRKLNK to try and access your QSYS objects. Normally, we only think of using WRKLNK to look at the IFS, but in truth WRKLNK views the entire IBM i disk as a set of hierarchical folders. It's just that the entire world of libraries and objects that we green-screen developers are so used to are sort of shoehorned into this structure, all in a single folder called QSYS.LIB. To access a QSYS library via WRKLNK, you just have to use the magical IFS pathname, which looks something like this:

Figure 6: The IFS pathname for a QSYS object is a bit intimidating.

As you can see from Figure 6, the IFS pathname is long and not particularly intuitive. Without too much detail, the gist is that the path is broken down into three or four chunks separated by slashes. The first chunk, QSYS.LIB, specifies the QSYS object space, the second chunk specifies the actual library, the third represents the object itself (and its type), and the optional fourth chunk is the member name, used only for source files (and occasionally database files). Oh, and note that the second chunk is not used If the object actually resides in QSYS! Anyway, hit Enter and you'll see a screen similar to the one in Figure 7.

Figure 7. This is what a source member looks like in the world of WRKLNK.

All of this is just to explain why the Remote Systems View looks the way it does. It's simply not something that we green-screen programmers are used to, any more than we're experts at the IFS. The only reason I'm a little more comfortable than some is because I spent a lot of time writing Java code, and that requires the IFS frame of mind. But IBM understands that green-screen programmers are more familiar with the QSYS world, and that's why they created the Object Table View.

RDi's Object Table View

I'll close this article with an introduction to the Object Table View. It's easy to get to the Object Table View from the Remote Systems View, as I show in Figure 8.

Figure 8: Right-click on a source file and select Show in Table to see the members in a PDM-like table.

Right-click on the object whose children you wish to see. Figure 8 shows me right-clicking on the QMODSRC source file. That brings up a context-sensitive menu (as right-clicks do throughout RDi). From that menu, select Show in Table and the table will magically appear! Where does it appear? Well, that depends. By default, it shows up in that short, wide stack at the bottom of RDi, which unfortunately isn't particularly useful, but the good news is that you can move it (or even tear it off entirely), and RDi will remember your last choice the next time you show it in a table. Here's what the view looks like when it has enough room to stretch out:

Figure 9: The Object Table View looks a lot more familiar to PDM experts.

Yeah, now that's got a little PDM in it, right? Anyway, that's for the next article where we will dive deeply into this view: how to configure it and how to use it. And then finally we’ll get into the new PDM perspective that ties it all together. For now, make sure you're familiar with the Remote Systems View; as midrange developers we need to spend more and more time outside of the QSYS world, and the Remote Systems View is how we do it.