"Its continuing mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no one has gone before."
--The mission statement of Star Trek: The Next Generation

The mission of the Remote System Explorer (RSE) is similar to that of Star Trek. But instead of space, it explores the traditional QSYS library system that we know and love. It also provides direct access to the IFS in a way that up until now required a shared folder and a mapped drive. The WDSci developers have done a fantastic job of bringing most of what we need down to the desktop. A couple of areas are lacking in functionality, but given the features that have been included, it's hard to fault the developers for not getting everything done. Except maybe spooled files...

The RSE is really what puts the "i" in WDSci. Most of the other features of WDSci are pieces that come along with the WebSphere Studio Site Developer (WSSD). Those of you who have the advanced version of WDSci also get the goodies included with WebSphere Studio Application Developer (WSAD). These are primarily EJB-related tools.

But the RSE is the primary vehicle for accessing the iSeries-specific stuff, and it's what really makes WDSci a powerful tool in your development arsenal. It allows access to objects on the iSeries, both in the QSYS library system and in the other library systems. It allows communications with and transfer between multiple iSeries machines. You can edit, compile, and debug iSeries HLL programs, using a graphical debugger on your workstation. The editors are color-coded and context-sensitive, even providing code assist features. And since the entire toolset is built on top of the Eclipse framework, you can add your own extensions (such as spooled file support...).

Here's what I'll review in this column:

1. The Remote Systems Navigator
2. The jLpex editors
3. The Integrated iSeries Debugger

Each of these topics is a large area by itself, but I will endeavor to give you at least a taste of all the capabilities in each area. And rest assured that the team is not resting on its laurels either. The WDSci developers recently circulated a list of possible enhancements to the product, asking developers for their input into the features most needed. Among these were things like embedded SQL support (the number one vote getter!) and wizards to convert from fixed-format to free-format. The latter is something I would like to see as I continue my journey into the strange and exciting world of free-format RPG (a topic for another day).

It's clear to me from looking at the list of proposed enhancements that the team is charting a new course for IBM tools. Prior to this, I think that IBM's philosophy was to provide only the bare essentials and let the third-party market make up the slack. With the new features in WDSci and the ones being proposed, that philosophy seems to have been abandoned. Instead, IBM is trying to provide serious developer-friendly tools that will allow you to do your entire job right in the WDSci workbench. As I pointed out last month, I think the team has done an admirable job on this front with the Web application development tools. Building a Web site is a very simple, self-contained task, and I never had to leave the workbench. They're not quite there yet with iSeries program development, but they get closer with each iteration.

The Remote Systems Navigator

At its most fundamental, the RSE is simply another Eclipse perspective. It has views just like any other perspective, and it even shares the editing pane. This latter bit is important, because it means you can edit both traditional iSeries source such as RPG code and non-traditional objects such as XML files side by side. You can see an example of this in Figure 1.

Figure 1: In RSE, you can edit RPG and XML side by side. (Click images to enlarge.)

In Figure 1, the view in the upper left is the Navigator. If you look closely, you can see that it allows access not only to traditional iSeries objects (libraries, objects, and members) but also to IFS files. You can move objects from one library to another and copy data members from one file system to another. For example, you can take an iSeries database member and copy it to a flat text file on the IFS.

My configuration has a connection only to my development machine, but you can have connections to multiple machines simultaneously. While I haven't tried it, I understand that with the tool configured that way, you can copy objects from one machine to another. Perhaps someone who has experience doing that will comment in the discussion section at the end of this article.

The navigator has a number of predefined views, such as your current library list and all user libraries. The current library list is set based on your setup preferences for the connection, as shown in Figure 2.

Figure 2: The "Subsystems" tab of the connection properties allows initial setup of libraries.

You can list the libraries you want in your library list, or you can specify a startup command. In my case, I have an environment setup command, SEL, that sets my library list for me. All I had to do was enter that command in the "Initial command" box, and whenever I start up the workbench, the connection is established and that command is run, setting up my library list correctly.

In addition to the standard lists mentioned above, you can also easily create your own "filters." Filters are sets of objects that you can use just like predefined lists. For example, you can set up a filter for all the source members in all the libraries that match a certain generic naming pattern. It's great for being able to see all the members in a multi-library project.

The Navigator is more than just a Windows Explorer look-alike, though. Not only can you navigate through one of those lists, you can also then show the list in a table view like the one in Figure 3.

Figure 3: You can show a filter in a table view like this one, with sortable column headings.

Normally, this view is at the bottom of your screen; in Figure 3, I've expanded it to fill the whole workbench. One of the nice capabilities of Eclipse is that you can maximize any view this way, so you don't have to constantly resize panes to see detail. But the Navigator doesn't stop there. You can now turn this view into a "fast view" via a simple menu option, and it will then be available in the left-hand toolbar for single-click access.

And this same filtering capability is available for IFS objects. The Navigator is a very powerful way to arrange and access iSeries objects of all types.

The jLpex Editors

As I noted in my last "Weaving WebSphere" column, there is a little bit of a naming discrepancy concerning the editors in WDSci. The folks at IBM call them the LPEX editors, which was the original name for the editors used in CODE/400. But those editors were written in C/C++, while the editors in WDSci are entirely rewritten in Java, and they really are new animals. Therefore, some of us in the field refer to the WDSci editors as "jLpex" to distinguish them from their CODE/400 ancestors.

Regardless of what you call them, the editors continue to progress. The beauty of the Eclipse concept is that, because all editors are of the same design, they can all coexist. You can edit anything--be it RPG, XML, HTML, or CSS--all in the same view. In fact, because of the split-screen capabilities of the editor, you can be viewing XML in one pane while editing RPG in another. Everything is color-coded and context-sensitive, depending on the capabilities of the jLpex editor for that language. Figure 4 shows a typical context assist in free-format RPG.

Figure 4: The jLpex editors provide context-sensitive at the click of a button.

The CL editor allows you to prompt for the values of a CL command. The formatting done by the CL editor is a little different from that of SEU and takes some getting used to. In fact, some people turn off that particular feature. From the Preferences menu, you can do that as well as customize many things, including the fonts and colors for the editors.

One of the nice features of the RPG editor is the procedure wizard. It allows you to easily specify all the characteristics of a procedure, and then it does all the grunt work required to generate the stub for the procedure, including the prototype. All you have to do then is fill in the code! Figures 5 and 6 show the wizard and the generated code, respectively.

Figure 5: This is an example of the procedure wizard. The generated code is in Figure 6.

Figure 6: The procedure wizard generated this sample code.

The prototype is placed at the beginning of your code in the proper place, and the procedure itself is added to the end of the code. Personally, I'm looking forward to an enhancement that will allow me to modify an existing procedure, but this is a great start.

The Integrated iSeries Debugger

The Integrated iSeries Debugger has got to be one of the coolest features of the new tool. With the debugger, you can set a breakpoint in the source on your workstation. Next, you "launch" the program, which submits a job to call the program in batch. When the program hits your breakpoint, control is returned to your program and the debug perspective is automatically opened with your source positioned to the breakpoint.

Getting My PTFs On

But before I delve into that, I'd like to give kudos to the team that determines the compatibility between the workstation and the host. For some reason, I did not have a couple of required PTFs applied on my system. Rather than just fail, WDSci brought up the display in Figure 7.

Figure 7: The debugger notified me that a PTF was missing and told me how to find more information.

At the top of the window, a clearly worded message told me what the problem was and how to get more information. I followed the instructions and got the notification shown in Figure 8.

Figure 8: The specific numbers of the missing PTFs are detailed in this panel.

I then went to the Internet PTF facility (iPTF) and downloaded the appropriate PTFs. I applied them, and in just minutes I was able to try the debug session again. And this time, it worked perfectly! My wish here is that the WDSci developers could somehow automate this procedure as well, allowing me to download and install PTFs directly from WDSci, but for the time being, this is a very graceful way to handle the situation.

Continuing Forward

Once I had the PTFs applied, the debugger worked exactly as advertised. I simply launched the program, and WDSci submitted a job on my iSeries, ran the specified program, and then stopped at my breakpoint, bringing up the display in Figure 9.

Figure 9: Here, the debug perspective shows the source with the breakpoint highlighted and the monitor view.

Among the views available in the debug perspective is the monitor view, which allows you to view variables in your program. You can also modify the variables. Another feature is the Watch Breakpoint, which will stop your program if the contents of a certain address are changed. This is a very powerful way to find those nasty bugs where a global variable is being updated unexpectedly.

I have not yet tried debugging an interactive program this way, although the documentation implies that it can be done. I think a small emulator window will be displayed, but that's not something I will have the time to look into any time soon. If you have experience with this feature, please let me know.

Meanwhile, for more detail on the debugger, read our recent article by IBM insiders Vadim Berestetsky and Inge Weiss, "Debugging with IBM WebSphere Development Studio Client Version 5.1."

So Can WDSci Replace the Green-Screen?

WDSCi isn't quite yet ready to replace green-screen 5250 development. Several features are still needed before that can happen. I alluded to spooled file support earlier. I think this is probably pretty high on the WDSci team's list.

Basic system status functions like WRKOUTQ and WRKACTJOB are still unavailable, although they are being considered. Without those, you'll probably still need your Client Access session. This latest version of WDSci has some additional wizards for creating message files and data queues; I hope to see continued improvement in this area, and as more commands become available, we'll need the green-screen less.

I didn't get a chance to cover the iSeries Project feature in this column. I haven't used projects much, but some people are very positive about them. I also know that the WDSci development team is hard at work enhancing this feature. If it's important to you, let me know, and perhaps in another column I'll take a closer look.

And remember: It's not all about IBM, either. It's important to realize that since WDSci is based on Eclipse, one of the fundamental features of the tool is the ability for people other than IBM to provide additional features. For example, until base WDSci supports spooled files, the fine folks at SoftLanding have made a spooled file viewing plug-in available. I haven't used it, but many people have, and they say it's a very nice addition to the workbench. If you get ambitious, you might even try writing your own plug-in!

I look forward to IBM continuing to extend WDSci. The features already in place are a big improvement over the existing green-screen interface, and because of the increased productivity of the interface, I currently find myself spending well over half my development time in the workbench. That's an awful lot for an old green-screen dinosaur like me. I think IBM's goal is to eventually replace all of the features of green-screen development, and all I have to say is:

Make it so!