I mentioned Enterprise Generation Language (EGL) in a previous column, along with a number of other new advanced technologies available on or around the iSeries. Although EGL is a little hard to describe, you can think of it as sort of a high-level scripting language for applications. One of EGL's marketing points is that you can create an entire application in one source file, which is certainly different from what we're used to in either in the green-screen world of DDS and RPG or the Web world of JSP and servlets.

But is this new language really a replacement for RPG? I decided to give EGL a test drive to find out whether I liked it or not. You probably know my bias: RPG for business logic with a very thin Java layer communicating to JSP Model II for the user interface. Those tools are so very powerful that it's hard to believe a single language, no matter how well thought out, could replace them both.

My goal here is to try to decide whether EGL can be used as a replacement for RPG. By this, I don't mean necessarily trying to justify replacing all RPG code with EGL, but instead trying to determine whether application development using EGL is, even potentially, as easy as using RPG. To do this, I'm going to first follow the tutorial and identify any ugly bits that would stymie an RPG veteran from moving to this language. Then, I'm going to try to modify the tutorial application and see how easy it is to make changes to existing code. The last step will be to attempt to create something from scratch.

Getting Started

Unfortunately, the very first thing we run across is what can best be explained as a rather shaky alliance between the Rational and WebSphere product lines. I don't know the genesis of the problem; lots of WebSphere folks are on the Rational team, and the toolsets both share the same common Eclipse underpinnings. But the cooperation between the two groups is less than stellar, and this fact is readily apparent in the most basic of actions: updating the tool.

Rational Product Updater

In line with the rebranding of everything in sight with the Rational name, you now update WebSphere Development Studio Client (WDSC) via something called the Rational Product Updater (RPU). And if you're directly connected to the Internet, the installation process is said to work flawlessly. You probably noticed that I'm not giving it my stamp of approval; that's because the download is about 1.8 GB, and on a really great day that's about 22 hours of download on a 192 KB DSL line. Even on a full T1, if you've got just 20 workstations, you're talking about an aggregate of some 50 or 60 hours of bandwidth. I brought this to the attention of the EGL team, and as they attempted to address my concerns, that's when things got messy.

It started out pretty hopeful: I was instructed to let the updater update itself. A relatively small (600 KB) download would enhance the RPU to be able to use local files to update the product. This went smoothly. And then confusion set in.

Never the Twain Shall Meet

The whole issue started with the fact that the EGL tutorial needed to be updated. To do that, I needed to update to Version 6.0.1. And since I decided that the "recommended" approach of a 22-hour download was not really the right thing for me, I instead needed to update using the alternate methods. However, there was some confusion as to which alternate method I needed to use. You see, I first tried to download the WDSC changes from the WDSC site (>300MB for Standard Edition, >400MB for Advanced). As it turns out, though, these changes are only for the iSeries portion of WDSC. They do not update the "base" portion of the Rational development tools, and it is the base portion that houses the EGL toolkit (including the tutorial I was trying to test). In order to update that part of the tool, I had to go through a completely different process, and that process wasn't quite soup yet (the version I was directed to meant setting up an internal HTTP server just to serve up the fixpacks).

The bright side is actually twofold. First, the EGL team got together and got me a DVD with the Rational product updates, which proved that the local fixpack approach is viable. Second, the EGL folks assure me that they recognize the need for a centralized download and distribute technique for delivering fixpacks, and they're working to make this method one of the standard methods of fixpack dissemination.

The downside is of course the fact that this isn't already in place. I have a version of WDSC in which the Rational parts are at 6.0.1, and the WDSC bits are at 6.0.0. To be perfectly honest, while I understand that the Rational team and the WebSphere team may have different priorities, that sort of crosstalk shouldn't affect me, the end user of WDSC. Someone needs to be responsible for the interoperability of these product lines, making sure that at the end of the day the WDSC user has one place to go for all fixes, be they Rational- or WebSphere-originated, and that person needs to have a sense of what it takes to deliver products to the SMB users that IBM professes to be courting. Requiring every machine to download 1.8 GB is not a viable solution, nor is having to go out and find multiple fixpacks to download and install on each machine. As I said before, the EGL folks assure me this is in process, so let's see what they do.

On to the Tutorial

The good news is that the tutorial looks to be of a very good quality. It really doesn't expect much of you at all; it takes a very simple, step-by-step approach with lots of pictures and explicit instructions. That means I should be able to get something running with a minimum of fuss.

A Warning

One little problem with the tutorials: A dialog in the workbench "freezes" the tutorial window. This is a UI design issue. When a dialog box pops up to prompt you for information, the underlying workbench is usually disabled. This happens on most Windows applications, not just WDSC. In WDSC, you'll find that if you try to click on the workbench when a pop-up dialog is displayed, the title bar of the dialog flashes, signifying that you're trying to engage the parent window while the dialog is in control. This is called a "modal" dialog, and it's really a good idea; it keeps you from trying to do too many things at once and perhaps leaving a pop-up stranded out there.

Unfortunately, the tutorial window seems to share the same event handler as the base workbench. Because of this, when a pop-up dialog is shown not only can't you interact with the workbench, but you can't interact with the tutorial, either. Since working with the dialog brings the workbench to the top of the stack, it overlays the tutorial so you can't see the tutorial anymore, as you can see from Figure 1.

Figure 1: When a pop-up dialog comes up, you can't read the tutorial anymore. (Click images to enlarge.)

What I did to avoid that problem was to resize the windows in such a way that I could walk through the tutorial and also at least see the tutorial instructions. This meant having the workbench and the tutorial window share the desktop, as shown in Figure 2.

Figure 2: By resizing the workbench and the tutorial, I could see both.

The EGL team assures me that my complaint has been forwarded to the Eclipse team and that the ability to use the workbench without locking up the tutorial window is already accepted as a needed enhancement, so this problem will disappear in a future release.

Tutorial Ho!

In the previous version of the tutorial, the configuration steps involved actually tweaking the WebSphere Application Server instance using the administration console, which is somewhat less than intuitive to old-time green-screeners like me. This new version avoids all that claptrap, and with a few simple instructions the project was up and running. I'll note a couple of discrepancies here:

1. In Step 3, you are instructed to display the Project Explorer view and then look at the EGLWeb project. Unfortunately, the EGLWeb isn't immediately visible; you need to expand the Dynamic Web Projects category to find it.
2. In Step 4, you're given instruction on how to look at the EGL dataparts, but the instructions say to expand Dynamic Web Projects -> EGLSource -> data. The correct path is Dynamic Web Projects -> EGLWeb -> EGLSource -> data; the instructions miss the EGLWeb folder.
   
3. In Step 6, when I went to run the first version of the JSP, the server gave me an odd error: something about concurrent modification problems or something like that. I didn't take very close note and simply tried to re-run the JSP. That worked, so I don't know if the error was something you're likely to see or just an artifact of something screwy I did during setup.

Smooth Sailing, but Where?

From this point forward, everything went quite smoothly. I managed to follow each step of the tutorial successfully, and at the end of the last step, data came up in my browser. It was actually quite gratifying to see that a simple, straightforward sequence of steps could bring data to the screen, but any number of tools can do that: I needed to see how easily I could change the application.

While not completely intuitive, it wasn't too difficult to realize that I had to modify the "data table" object on the JSP. It took a couple of attempts, but eventually I was able to isolate that component (as opposed to one of its columns or a larger table that it was embedded in). Once that was done, I could select the properties of the table and change which columns were displayed in the table. Since the data was selected using an SQL SELECT statement, changing which rows were displayed could be done as easily as changing the SELECT criteria. Also, I am reasonably sure that the EGL language allows me to change the contents of the array after I've read it in from the database, although that's a more advanced exercise for another day.

So What Do I Think?

I'm intrigued. A very unexpected capability of the tool springs from its use of (or more precisely, its dependence upon) the JavaServer Faces (JSF) syntax. Personally, I find JSF to be over-engineered and needlessly complex (the dataTable tag is a good example). However, EGL seems to be able to bridge that gap in such a way that the EGL developer doesn't need to know that much about JSF. This could conceivably overcome some of the ungainliness of the JSF specification itself.

However, I haven't been able to run the tool through its real paces yet. Obviously, a short tutorial isn't going to show off much of the ability of the product, and unfortunately the tutorial that is supposed to really exercise EGL's capabilities is part of a four-and-a-half day course, so it's not something I can do justice to within the confines of this introductory article. The introductory tutorial is a simple database query application, and we need to do something far more complex to really test the features of the language. My discussions with Bob Cancilla make it clear that this first tutorial is really more of a Hello World than anything else and that hooks exist for a more advanced message-based approach; in fact, he insists that the support for IBM's MQ Series messaging product is very powerful. And after what cursory examination I was able to do within the scope of this first tutorial, it seems to me that the basic EGL language could just as easily use components that aren't based specifically on any physical database entity.

That being the case, I'm comfortable that the tool warrants further review as a possible high-end development tool. I have some concerns; the fact that the tool is very opaque (by which I mean that it uses proprietary runtime methods for which no source is supplied) is my biggest objection. Also, I've been told that the only procedural language targeted will be COBOL, not RPG, which once again shows the rift between the Rational folks and the typical iSeries developer. But I'm still game to give the tool an in-depth workout as time permits.

The Ongoing Saga of Hardware Procurement

This column's installment of the hardware saga is not going to be the warm, fuzzy patch it's been in the past couple of months. My xSeries experience, at least from a fulfillment side, has been less than fantastic. Whereas I have a shiny new i5 and have had it for some weeks now, when I started this article the xSeries had not yet arrived.

Add this injury to the insult of having had to wire the money in advance to IBM (sorry, no credit cards accepted!) and it's been a little bit of a fiasco. I wired the money back in mid-October, and first the order wasn't properly processed, and then some other unidentified snafu held up the box again, and then somehow on its way from Guadalajara to here, the box got held up by the FDA. Why IBM hardware is being held up in FDA inspection for two and a half days is beyond me; you'd think that IBM would have worked the kinks out of that process a long time ago, but evidently that's not the case.

However, the box finally arrived, and for the most part I'm thrilled with the machine. But I'm a little ticked off that nobody warned me that some truly bizarre design decision centering on remote workstations limits the maximum screen resolution on my $3,500 machine to a paltry 1024x768 (my sub-$500 hand-assembled Wintel box does better), but other than that, the machine is fast and powerful. I'm going to try a second video adapter to get around the resolution limitation, but IBM refuses to acknowledge that this will work.

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..