"When I was younger, so much younger than today, I never needed anybody's help in any way."
--John Lennon and Paul McCartney

It's a beautiful Friday in June. The birds are singing, the sun is shining, and you're trying to get a program written so you can get the heck out of Dodge and away for the weekend. What's the quickest way to get done? SEU or WDSc?

Well, if this were Java we were talking about, it would be a no-brainer. WDSc is hands down the most productive Java development environment I've ever used. However, the jury is still out on WDSc as an ILE development tool. For those of you who like the Cliffs Notes version of things, here's the summary of this article: WDSc is very good for RPG, is OK for COBOL, and needs some work on CL. However, there are really cool things going on with the editors that bode well for the future, and I invite you to walk through some of them with me.

Why Use WDSc at All?

I'll always fall back to a simple answer to this question: You'll probably need it someday. Why? Because all the neat features, from new languages to new capabilities, will be added to WDSc, not to SEU and PDM. That's just the nature of the beast. And since we've heard that there will be a WDSc "lite" with only iSeries editing capabilities in place, the size of computer required to run the software may be less of an issue.

Not only that, but once you get your hands on WDSc, you can begin to dabble. In what? In just about anything that strikes your fancy. From Java to JSP to Web Services, all of these are available in WDSc for you to play with in your copious free time ("copious" is tongue in cheek, but building your skill set is no longer a luxury; it's a necessity).

But It's So Slooooooow!

I hear this a lot. A lot of people in our industry argue that WDSc is just not as productive as SEU. I can even understand the argument if you look at it a certain way. For example, if you're talking about coming in from a dead stop with your PC turned off and making a two-line change to a program, then certainly SEU via iSeries Access is going to be quicker than loading WDSc and modifying the program that way.

But that argument doesn't really hold, because if we were always looking for the fastest method, we'd all have dumb tubes on our desks, since it's a lot quicker to flip on a tube and get a sign-on screen than it is to wait for Windows to boot and then run iSeries Access.

"But," you say, "we don't have to wait for Windows to boot because our machine is already up and running!"

Yes indeed! And in a proper development environment, you also don't have to wait for WDSc because you have it up and running as well. I start WDSc when I start work in the morning, and it runs all day. Often it runs overnight and is ready for me in the morning! The biggest problem with WDSc is if for some reason you have to switch workspaces. That can take a minute or two, but hopefully it's a fairly rare occurrence (and a good excuse for a cup of coffee).

OK, WDSc Is Not Evil in and of Itself

Good! I'm glad we got that far. Now it's time to take a look at the jLpex editors and find out what they're doing. (Author's Note: I continue to refer to the editors in WDSc, which are written in Java, as "jLpex" editors in order to distinguish them from the older LPEX editors written in C. Someday, I may have to change that and use the less precise term LPEX, but for now I am sticking with jLpex!) I'm going to split the editors into four groups: RPG, COBOL, CL, and "other." That's because for the most part the "other" editors don't have many features short of keyword highlighting rudimentary syntax checking.

RPG

Easily the best of the bunch, the RPG editor is a very powerful editor indeed. It has all of the many powerful features that the jLpex editors share (such as a combination of line editing and cursor-based editing), and in addition the RPG editor is highly integrated with other views and features.

For example, when you're editing an RPG source member, the RPG outline view is particularly powerful. As you might expect, it displays a list of the files, fields, procedures, and subroutines, but it goes far beyond that. Every field can be expanded to show references. In a particularly nice move, the folks in charge of the outline even have a visual cue (an asterisk) that identifies whether a field is being updated. The same holds true for indicators. Not only that, but "complex" objects such as data structures and files can all be expanded: data structures to their fields, and files to their record formats and further to their fields. And the same cross-reference capability of seeing where each object is used is available at each level. Figure 1 shows an example of the outline view, with a reference to a field in a file selected in the outline view, which in turn highlighted that line of code in the editor view.

Figure 1: Selecting a reference to a field in the outline highlights it in the source code. (Click images to enlarge.)

These features are available only if you refresh the outline. I think this makes sense; I have to believe that trying to keep the outline in sync with every keystroke would be a massively CPU-hungry task. Instead, if you need the outline, you simply refresh it. Another bonus of the outline is that once it is refreshed, you can use content assist to help write code. Hitting Ctrl+Space during editing will instruct the editor to attempt to find the appropriate completion for the code you are typing. For example, if you type a letter and press Ctrl+Space, the editor will bring up a list of fields that begin with that letter. You can select from that list, and the editor will type the rest of the field name for you. Figure 2 shows an example of content assist in action. I typed "saveField = UT" and then pressed Ctrl+Space. Content assist brought up a selection window with a list of fields that start with "UT."

Figure 2: Content assist will help you write your code.

Yet another feature: In fixed-format RPG (III or IV) you can prompt for a line and a dialog will be displayed that allows you to fill in the line. The dialog has all the specification-exclusive fields and their appropriate values (for example, the opcode field on the C-spec dialog has a dropdown list with all the opcodes), and while it's a bit cumbersome to me, it would certainly be helpful to beginning RPG programmers. (You can also prompt for free-format RPG, but all you get is a long blank line to enter code into; there's no code assist or prompting available.)

And of course last but not least is the built-in feature of converting fixed-format RPG IV to free-format. This enhancement alone makes a powerful argument for using WDSc, especially if you plan to transition to free-format RPG.

COBOL

The COBOL editor is significantly less powerful. The outline view shows a selected subset of information, including 01 and 77 level fields, procedures, and a few other things, but the detail is nowhere near the detail the RPG editor has. As far as I can tell, there is no content assist anywhere in the editor, although it does perform syntax checking. Figure 3 shows the outline feature for COBOL.

Figure 3: The outline feature for COBOL is not as fully featured as that of RPG.

CL

The CL editor is the one that most people point to as a demonstration of the superiority of SEU. And in previous releases, I have to admit it was pretty horrible, primarily because the editor had only one CL-specific feature, command prompting, and that didn't work quite the way we expected. If you allowed the editor to format a prompted line, the command was positioned in the first column, and the rest of the command wasn't much better. It was a maximum use of space, I suppose, but it was different than what it was in SEU and of course that's enough to make people a little crazy.

But even though that was a valid example of WDSc not quite measuring up, it's also a perfect example of why you should move to WDSc: Because they fixed it! In the current release of WDSc, not only do those settings default to the same columns as in SEU, but you can override them. The jLpex teams are really working hard to make the editors better for all of us. How many such enhancements do you expect to see in SEU?

Other Editors

The other editors don't really have much going for them other than highlighted syntax (which is a nice feature but not much of a reason to move to WDSc) and some syntax checking. I can understand that the DDS editor isn't going to get a lot of features, although a visual editor for display files is something we'd all love to see. I'd personally like to see the REXX editor with a little better support; it doesn't even have syntax checking. And I was really disappointed to see that the C editor didn't support an outline feature. But there are only so many dollars, and you can't get everything.

Common Features

Then there are the features common to all of the jLpex editors. The fact that these features are common means that once you're used to using them in one language, you can transfer that knowledge to other languages. The only caveat is that the non-iSeries editors (such as the Java editor) don't have all of these features.

It's a Line Editor! No, It's a Text Editor! It's Two Editors in One!

First off is one of the most bizarre but wonderful features of the slightly schizophrenic editors that make up the jLpex family. Each of them supports the standard text-editing features that a PC-based text editor supports: marking a block of text, cutting or copying and pasting it using either menu options or keyboard shortcuts, changing the case of chunks of text from upper to lower, that sort of thing. But they all also support the full range of line editing commands from SEU, including things like block copy, multiple copy/move (which they finally fixed), repeated copies, and so on, all using the familiar line commands like CC/CC/A3 (the first two CCs mark a block of lines to copy, while the A3 identifies the target line and copies the selected code after that line three times).

So, the jLpex editors help you transition from the line-oriented SEU world to the more mouse-based or at least cursor-based environment of standard PC test editors.

There are some features that don't work very well still. Splitting lines is particularly painful. The editor should know that splitting a free-format C-spec should at least force the first character to be past position 6, but it doesn't, so you end up with a bunch of errors until you manually move the line over. While I suppose forcing this behavior might somehow cause problems elsewhere, I'd at least like a preference setting that would allow me to split lines intelligently.

The Hidden World of Commands and Actions

This is the area where I think we're really going to see some cool things. You may not know this, but the editor has a whole set of commands and actions that can be invoked.

The difference between a command and an action is that a command can be invoked directly from the command line. You get to the command line by pressing the Esc key while you're in the editor. You'll see the cursor positioned to an entry field at the bottom of the editing pane. Here, you can enter commands such as findText, which as you might guess will find text. These commands are typically a bit more powerful than at first meets the eye: The findText command can optionally replace the specified text, and do it multiple times, within identified columns, and so on.

Actions, on the other hand, can be assigned to keystrokes or menu items. Typically, these are more granular activities, such as moving a cursor or marking a block of text. And while it may not sound particularly thrilling to be able to move the cursor, these types of actions can be very powerful, especially when encapsulated in some sort of macro. The jLpex editors, being a part of WDSc and thus a part of Eclipse, are very amenable to creating these sorts of macros. If you remember that the Eclipse platform is built to be extended, you might not be surprised to learn that you can write your own Java classes that can then be attached to the editor (via a "plug-in"). These classes can then be used (like macros) to do everything from spell-checking your literals to providing complete generators for things like procedures. That's why I don't worry too much when someone says they don't like how the editors work; if it's really that much of an issue, you can always write your own extension to the editor!

Documentation describing the APIs that can be invoked is quite extensive. You can execute any standard command, as well as any action. You can even dialog with the user, in effect creating your own "wizard" to walk through complex development tasks. I think that this capability may be one of the future strengths of the whole process; if you have corporate programming standards and a set of standard APIs that you use in development, you will be able to write macros that will act as expert systems and walk people through basic programming tasks. This will definitely help you keep standardized and boost productivity as well.

So Are You with Me?

I hope that through a few pictures and a little bit of discussion, I've shown you that the benefits of WDSc are quickly outstripping any negatives. Not only that, but as the product matures, the negatives will be resolved while the positives will only multiply. Eventually, SEU will be pretty much a footnote, something like the difference between a plain ASCII text editor and a word processor like Word or WordPerfect. And those of us who have embraced WDSc will find our jobs a lot easier.
And this is just about editing ILE code; I didn't even touch on using WDSc as a verification, compiling, and debugging tool in an ILE environment. If you're interested, I'll address that in another article down the line. Let me know.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..