Our inventions are wont to be pretty toys, which distract our attention from serious things. They are but improved means to an unimproved end.
—Henry David Thoreau
Thoreau is considered an optimist. That's why the statement above has a particularly dark tone to me. Of course, Thoreau was something of a Luddite, so I suppose I can understand his distrust of all things invented. Then there's the other end of the spectrum, where all that glitters is gold and the shiniest new tool is the one that we simply must use. These polar attitudes are too common among the System i population when it comes to WDSC: A gulf exists between those who hate it because it's not SEU and those who want it to be a brand new paradigm that completely displaces the legacy systems.
Meanwhile, in the middle, the WDSC developers have managed to create a remarkable piece of software despite having perhaps one of the most difficult jobs I can imagine: bridging the gap between the Rational and the System i development worlds. That job must be particularly difficult when most of the people you work with either unashamedly admit that they want to get rid of legacy languages and perhaps the platform itself, or at least seem to quietly share that view by way of their actions (or lack thereof).
I think that a lot of System i developers appreciate the prodigious amount of work the WDSC developers have accomplished. As soon as I can, I'll write a WDSC 7 column for programmers that will cover more of the in-depth things they need to know. This article, though, is directed toward management. If you are a manager of software developers, I want you to see what the WDSC development team is to providing to your staff. They have gone the extra mile in so many ways that it's almost criminal if you don't try to get your programmers to use the tool. And if you're a developer having a hard time getting buy-in on WDSC, I want you to show this article to your manager. This is not just a shiny new toy.
I also think it's important that we in the development community applaud the WDSC team for the job they've done to this point. We also need to make it crystal clear to the Rational group—now nominally in charge of the WDSC product—what we need and expect from future releases of the tool. There is an ongoing tension between the needs of System i developers and the "vision" of the Rational group, and I'll delve into that a little bit at the end of this article.
But for now, I'd prefer to focus on the tool itself and the remarkable forward progress it has made. Yes, there are a few flies in the ointment, but this release of the tool has made remarkable progress.
Begin at the Beginning
One of the single largest and loudest complaints about WDSC has been that the installation process is almost impossible to manage. The "integration" of WDSC with the Rational product line brought us the Rational Product Updater, a product that wasn't exactly the most intuitive thing on the planet. The new Installation Manager seems at first use to be much easier, much more polished, and definitely more stable. I used the tool to install multiple versions of WDSC 7 on multiple machines (including inside a VMWare virtual machine) with no difficulty, and later I was able to add a missing component without so much as a hiccup. I simply fired up the Installation Manager, selected Modify Packages, and checked the box for WebSphere Application Server 6.0. The utility did the rest.
Figure 1: Installing a missing or forgotten component is as easy as point and click. (Click images to enlarge.)
I still don't know what will happen with updates. I installed from a folder rather than from CDs, and as far as I can tell the Installation Manager went right to that location without my telling it to. Will I have to copy any updates down to that location? Will I be able to install updates off the Internet like I did with Rational Product Updater? Those questions will have to wait until the first fix pack, due out very soon now (in fact, it may be available when you read this).
By the way, you may have gotten the idea from Figure 1 that you could selectively install bits and pieces of the tool. You would be absolutely correct. And while it's not entirely clear exactly which bits you might need for a given job, I don't mind because it's really easy to add a feature if I need it.
Look What They've Done to My Workbench, Ma!
The workbench is a great example of the work that the team has accomplished. Since Version 6.0, the workbench has sported a flashy little Welcome screen that performs two distinct functions. One function is to enable or disable development "roles." Disabling unused roles helps to reduce the complexity of the interface by removing the associated options; this feature is still pretty much unchanged (albeit expanded a bit). The other function of the Welcome screen is to provide a point-and-click introduction to an absolute wealth of information about the tool itself.
Figure 2: This is the Welcome screen, poised to enter the Tutorials section.
Again, this idea of clickable circular icons is the same as the previous version, except that there's a neat new feature. If you click on the folded arrow icon on the upper right, the Welcome screen will be minimized to a set of icons on the lower-right edge of the workbench.
Figure 3: Clicking on the Workbench icon makes the Welcome icons available on the workbench.
This is a nice feature, because it allows fast access to any of the Welcome sections at the click of a mouse. This was entirely unnecessary, in the sense that I don't think any WDSC developers would have complained if the WDSC team didn't add this capability. In fact, I don't know how many people even know this exists, but it's a perfect example of the kinds of touches that WDSC 7 includes that you just don't find in other tool suites.
Figure 4: Here are a couple of WDSC views detached from the workbench.
Another feature way up at the workbench level is the idea of detachable views, although the feature can't be specifically attributed to the WDSC team. Instead, since this is an integral part of the more recent release of Eclipse, the whole Eclipse/Rational/WDSC family benefits from this concept: Whereas with Version 6 you could drag a view to any point within the workbench, now you can actually drag the view outside of the workbench as a "detached" view. This is reminiscent of floating menus in many other tools, but this is an entire view, such as, for example, the Debug Variables view, which can not only be dragged out of the workbench, but even off to another monitor. This is an absolute vindication for those of you who have provided dual monitors to your developers (and admittedly a little added fuel on the fire for those developers whose employers haven't seen the light).
A seemingly minor addendum to this particular achievement is the fact that WDSC 7 has been released on Version 3.2.1 of Eclipse. Not only is this a huge leap forward from the 3.0 release that WDSC 6 used (two entire releases), but also this indicates a much tighter integration with the state of the art, since the only later release is 3.2.2, which just became available in mid-February. There were a lot of complaints that WDSC 6 used a very old version of Eclipse; this certainly isn't the case for WDSC 7. Eclipse release 3.3 isn't even scheduled for delivery until late June of this year!
Author's note: This is one of those places where the whole Eclipse and open-source model works so well. However, all is not sweetness and light, as I'll later explain. But let's continue with the good side, shall we?
Lots of great things have been added to the platform in Versions 3.1 and 3.2, and I plan to publish a whole host of those features as tips over the coming weeks. Not to mention that the whole thing starts and runs a lot faster and requires less resources!
But the really incredible thing about WDSC is that not only do you get all the great features that are being added to the package as part of the open-source juggernaut that is Eclipse, but you also get System i–specific features because of the dedicated work of the WDSC team. System i developers truly get the best of both worlds in that regard.
Figure 5: The RSE Getting Started sheet is a nice introduction to the tool.
Another gripe I hear about WDSC is the learning curve. Personally, I find that complaint to be a little bit lame. RPG programmers are some of the best and brightest programmers I know, and how long did it take you to learn how to program an input-capable subfile? And anybody who has ever managed to get IBM's Report Layout Utility (RLU) to work can handle WDSC. But even so, IBM has expended some considerable resources providing an introduction to those who wish to be completely self-directed.
For example, when you first load the tool (and each time you create a new workspace), WDSC will display the Welcome screen previously discussed and shown in Figure 2, and then the iSeries RSE Getting Started screen shown in Figure 5 will come up. Once you get past the irony that IBM itself still calls the platform the iSeries (even more ironic: check out the package names for the JTOpen package; I'll leave that as an exercise for the reader), you'll find that this is indeed a respectable if somewhat limited introduction to the tool. Of course, I'm a bit biased; I give introductory hands-on seminars about the tool at user groups around the country, and I'm comfortable that you get more in a day with me than you will with the onboard tutorial.
Many things get added incrementally. For example, when the RSE was first introduced, one of the things you could do was see a list of either the members or the fields in a physical or logical file. OK, that's all fine and good, but of course System i developers being the grasping, immediate gratification lot that we are, we immediately asked for more.
Figure 6: The data table view is the next step in the evolution of the WDSC version of DFU.
And we got it! In WDSC 7, you can now list the contents of a physical file as well. It's far from perfect, of course. It works only on physical files; there are no capabilities for searching, sorting, or positioning; and my guess is that showing a really big file would probably cause some headaches. But it's a step in the right direction, and maybe some enterprising soul will decide to add some capabilities to this feature, such as being able to view an arbitrary SQL statement. Ah, wouldn't that be nice! But that's one of those things that will depend on us asking for more, I think.
How About the Editor?
Another big issue with WDSC has been one that shouldn't surprise anyone, since it also plagues the green-screen: Namely, support for embedded SQL has been a little shaky. A variety of errors existed in the early versions of WDSC, ranging from a stark inability to even process the errors to a subtle bug in which programmers thought they were modifying the embedded SQL source but were instead modifying the temporary generated member (which was then immediately wiped out by the next compile, thus negating all the work done in the previous edit cycle and greatly raising the programmer frustration level).
I'm happy to say that embedded SQL support continues to get better. The tool parses SQL statements and checks for syntax errors, although it doesn't yet add the accessed files and fields to the outline. Perhaps in another release.
Another feature that seems to be in an introductory state is the block capability. I've had two people ask me in the last month about whether WDSC had a feature similar to CODE/400's indent feature, which would show indentation. CODE does this by presenting a second view of the source with the lines literally indented.
Figure 7: This is the first pass of WDSC's indentation visualization.
WDSC is a little different. It shows an indentation tree to the left of the code. I'm not sure whether this is better or worse, but I can understand why the WDSC team did it because it will also work with free-format RPG. In any event, the initial tool is there, so now it's up to System i developers to decide whether they need it enhanced and the WDSC team to decide whether they have the resources to do so.
Unfortunately, All Is Not Wonderful in the Land of WDSC
By the time you've finished this article, you may have come to the conclusion that I've been immersed in a vat of the IBM Kool-Aid. However, trust me that this isn't the case. What I wanted to do was to present a management-level overview of some of the great new features in WDSC. I hope to write a technical piece that will go into more detail and really shake out the pros and cons of some of the design decisions. But I wanted to really press the fact that, from a System i development manager's standpoint, the tool has made impressive strides on nearly every front, becoming more productive and less resource-intense.
So what's the bad news? Well, there are a couple of things.
First, WDSC is based on Eclipse. While good in a wide variety of ways, this isn't an entirely perfect situation. For example, Eclipse 3.2 not only doesn't support 64-bit versions of Windows, it plain doesn't work on them. WDSC's Installation Manager won't even function there, and from what I can tell on the Eclipse site, there's really no sense of urgency about fixing it. This is the underlying danger of using Eclipse and its platform-dependent SWT implementation; if SWT isn't ported to a given platform, Eclipse (and thus WDSC) doesn't work. And while there has been a lot of attention paid to making sure Eclipse works on Vista, it works only as a legacy port, not on the new Windows Presentation Framework that forms the foundation of the new Vista UI.
Much more frightening is the ongoing idea of "unbundling" that keeps being presented by the Rational group. They seem to expect System i developers to pay for every copy of WDSC, and they want to do it by unbundling anything they can. They have already unbundled EGL, and there was rumor that both the new Application Diagrammer and the Screen Designer would be available only in the Advanced Edition of the tool. This rumor was given a lot of credence due to the fact that these two things appear only in the Advanced Edition of WDSC 7, although people at IBM who I talk to insist that at the very least the Screen Designer would appear in the Standard Edition of the tool.
However, there is continued talk about unbundling and making System i developers pay for various features of WDSC a la carte. This to me is the very height of insanity and is completely unjustified. System i clients already pay a premium: They pay extra for their disk, extra for their RAM, thousands of dollars for their compilers, and additional premiums for mandatory support and maintenance. As a manager, you're going to need to pound the doors of IBM to make sure they don't snatch defeat from the jaws of victory once again by trying to gouge System i clients.
As I pointed out in a recent article, and as I will continue to shout from the rafters as long as I have breath, the very best solution is simple: tack a premium of up to 10 percent onto 5722WDS and earmark that for the Rational group. For that "tool tax," System i shops get a fixed number of free licenses of the tool with everything needed to develop System i applications (this includes all Web development pieces, since that's the direction the platform needs to go; unbundling EGL was a huge mistake). The number of licenses depends on the processor group, just as the price of 5722WDS does. For shops that need more developers, make it relatively easy and not too terribly expensive to purchase additional seats. In this scenario, Rational would get money for every sale of an RPG compiler, as opposed to the scenario in which IBM unbundles the tools—one in which I guarantee you'll have lots of shops that will contribute zero dollars to Rational. Here's the real issue: If the tool is good enough to warrant the extra money, people will buy extra licenses. If not, it's a crime to force normal workaday System i clients to pay for the development of a tool that others won't buy.
Make sure you tell IBM to quit this unbundling nonsense. The System i is not a UNIX or Windows box with razor-thin hardware margins. The company makes enough off of you already; tell them to allow you to do your job without having to worry about trying to guess which tool might be "unbundled" in the next release. And tell them to please, please not touch things that aren't broken: Don't even think about separating 5722WDS into pieces...because that way lies madness.