"Things are only impossible until they're not."
--Captain Jean-Luc Picard

I have never been a fan of 4GLs (fourth-generation languages). That's probably the main reason I'm not particularly entranced by IBM's latest entry into the 4GL foray, the Enterprise Generation Language (EGL) that now comes standard with WDSC. Most 4GLs claim greatly increased productivity, platform independence, UI transparency, and a whole host of other benefits, few of which actually seem to see the light of day. Once in a while, though, a tool comes through that actually delivers on those promises. This article tells you whether EGL manages the impossible.

3GL, 4GL... What's in a Number?

Before I get to the specifics of EGL, I think it's appropriate to spend a little time talking about the various "G" languages. At this writing, just about everybody is in agreement about the definitions of 1GL through 3GL. 1GL is machine code, the ones and zeros that the computer actually reads and executes. 2GL is assembly language, where each line of code pretty much directly translates to some machine code (the fact that the lines are typically printed one at a time down a page is what led to the term "vertical microcode" that we used back in the pre-RISC days of the iSeries). And finally, 3GL languages are languages like RPG and COBOL (and C and Java and Visual Basic) that have their own syntax, in which each line of code can generate dozens of lines of assembly language (and through calls to system APIs, can execute hundreds or thousands of low-level statements). These languages are also called high-level languages, or HLLs.

The definitions of 4GL are less consistent. There are two distinct camps. The first considers the various SQL-like database languages to be the "fourth generation" of programming languages, pointing to the more English-like quality of being able to say SELECT TOTAL(SALARY) FROM EMPLOYEES WHERE DEPARMENT=101. Unfortunately, anybody who has tried to create a serious update realizes that the "English-like" nature of the language quickly reverts to programmer-ese as soon as the logic is nontrivial. A typical example used in SQL texts is updating the price file, with a statement like UPDATE PRICEFILE SET PRICE = PRICE * 1.025. In the real world, it's unlikely you'd ever do an update like that. In fact, you'd usually have a list of items and their new prices, with a statement like UPDATE PRICEFILE SET PRICE = (SELECT NEWPRICE FROM NEWPRICES WHERE NEWPRICE.ITEM = PRICEFILE.ITEM). That's not particularly "English-like" to me. In my opinion, the language isn't a candidate for 4GL until it understands UPDATE PRICE IN PRICEFILE WITH NEWPRICE IN NEWPRICES MATCH ON ITEM.

The alternate definition of 4GL languages is a bit fuzzier, but it typically involves a tool that allows the developer to specify programming requirements at a higher level. You define records and panels, and the tool writes code (typically in a 3GL) to actually access data and communicate with the end user. Early in my career, I was involved with one such tool, called AS/SET. A very simple 4GL (more like a 3.5GL), AS/SET provided two real features. One was the ability to define a "data model," which allowed you to define a header/detail relationship between files. The other was a set of templates for creating simple master file maintenance and inquiry programs.

Unlike many 4GL languages, however, you could also code from scratch to develop real business applications. This ability to bypass the templates and write your own code is the key to the applicability of a 4GL to different programming tasks.

So what's a 5GL? Those who use the term typically use it to distinguish between languages that are coded by standard source entry and languages that have a drag-and-drop type of interface. I usually don't use the term, because I consider a 5GL to be a subset of a 4GL.

Why Don't I Like 4GL Languages?

There are three reasons I don't like 4GL languages. The first is that they blur the already hazy line between data query and programming. The second is that 4GL languages are valid only if the tool's internal template matches the application for which the tool is being used. Finally, 4GL languages sometimes tend to reverse the progress we've made toward separating UI and business logic, combining everything into one design phase.

And When You Say Programming...

In the MC Press forums, you'll find a long thread discussing programming in response to my previous article "RPG and DB2: The Future Is Now" (look for part 2 of that article in a couple of weeks). In the thread, I express my opinion that there are really two broad categories of programming tasks: data extraction and data entry. The former involves getting data out of the database and displaying it to the end user, which a number of tools are designed to do. The latter, however, is the purview of the professional business programmer, and there are no tools other than standard 3GLs and brains. The business rules required to enter an order--even the most trivial order--are typically far beyond the ability of most English-language syntaxes or point-and-click interfaces. However, tool vendors and marketing types tend to gloss over such distinctions, leaving us with the idea that these new tools are replacing programming as a profession.

For example, I read this in a review of the latest release of WebSphere:

"Using only WebSphere Workshop, JSF, and SDO, a developer can design and assemble many dynamic business applications, using only drag and drop. No coding need be done for straightforward applications."

I won't get into a full description of Service Data Objects (SDO); I plan to do that in a later column. The Reader's Digest version is this: SDO is an access method designed by IBM and BEA to allow disconnected access to nontabular data. In non-Computer Science terms, it's the equivalent to an order query server that can return different records (header and detail). The inability to return different columns in each row is the biggest shortcoming of SQL. Nowadays, you can return multiple results sets with SQL, but there still is no sense of parent/child relationship--you can't easily have one header record followed by its children, then another header record followed by its children. SDO is an attempt to get around that and to provide an abstract layer that will allow you to access data whether it comes from a relational database, an XML document, or a message queuing mechanism.

But it's primarily a data display mechanism. There exists a sort of nod toward being able to use SDO for changing the database, but without a ton of back-end programming (including support for error reporting, which isn't even part of the specification), SDO won't be able to do anything other than simple queries. JavaServer Faces (JSF) is just a user interface, so by "straightforward applications" what the writer really means is programs with no more intelligence than a typical QUERY/400 query. This is not to say that you can't create complex queries with good business value, just that these have no inherent business logic. The only business logic available is what you can access via a stored procedure or a database server; nothing comes from the tool--this includes everything from security to pricing.

The Shoehorn Effect, or When Everything Looks Like a Nail

There is a huge difference between the work done by a 3GL such as RPG and a 4GL. Your typical 3GL is about removing the need for calls to the system APIs for things like database access and device I/O. Thus, the programmer in a 3GL is in charge of defining and implementing every basic application algorithm, such as record locking. You might not think that this a subject worthy of its own algorithm, but it's one of the most pervasive questions in application design. In a multi-user system, how do you prevent record lock waits due to long operator think time during master file maintenance? There are three standard techniques: lock the record the whole time, set a busy flag, or use a before/after image check. If you use none of these techniques, you have what we call "the last one to hit Enter wins":

1. User A reads a record.
2. User B reads the same record.
3. User A changes field X to 1.
4. User B changes field X to 2.
5. User A hits Enter and updates the record.
6. User B hits Enter and updates the record.

At this point, field X has a value of 2, and User A will never know that User B overwrote his change. For that matter, neither will User B. To avoid this, you need to use one of the collision control mechanisms I just listed. I'll forego explaining the implementation details of the three techniques, but each has its strengths and weaknesses, and it's a business decision as to which one makes more sense for your particular application.

Unless you use a 4GL tool, that is. 4GL tools are supposed to make application design "faster" and "easier," and the primary way they do so is by removing such design decisions. Instead, the tool designer usually decides which technique you will use. I suppose that a particularly well-engineered tool might give you the capability to choose between the various record-locking mechanisms, but given the nearly infinite number of design possibilities in an application of any complexity, it's unlikely that every design decision is going to be available by clicking a radio button on a wizard dialog.

The Return of the Monolith

One of the scariest downsides of a 4GL is that many 4GLs tend to push you toward monolithic design, rather than away. For example, most of the AS/400 tools that came out (such as AS/SET) had you designing the screen and the logic together in one "object," and it was up to the tool to actually create the DDS and the RPG. Typically, 4GLs don't embrace tiered architectures or object reuse, even though the components used by the tools may inherently support them. Each generated object is usually tightly bound to related objects, with little reuse.

If I could design an IDE, I'd design it so there would be tiers from the beginning. An object would be placed into a tier, and it would be made available to other objects through a set of messages (requests and responses). Only then would I worry about the implementation of each object. At that point, I'd be able to right-click on an object and set its property (iSeries RPG database server), and then a language-specific editor would come up, with stub code to support the various messages. The messages themselves could come from a UML design tool. Talk about productivity. Each object would only be responsible for its own messages. Maybe we can work on that next month, eh?

OK, So Joe Doesn't Like 4GLs

I though it was important to go through all this so that you knew exactly where I stood on the concept of 4GLs. This will allow you to take my comments on IBM's new EGL with an appropriately sized grain of salt. So now that you have the background, let me tell you what I found.

On the Positive Side

The tool seems to be well-designed. To my untrained eye, it's pretty clear that the original target language was COBOL; the idea of "levels" within a data structure are very derivative of COBOL data declarations. That's intrinsically neither good nor bad, and it's certainly as valid a technique as any other. But it might be a little bizarre for someone with no COBOL background.

There seems to be a great deal of support for green-screen applications. The definition of a "text form" includes things like validationBypassKeys, which is a way to say that the specified keys (for example, pf3 and pf4) will not trigger screen validation. In the iSeries/i5 display file world, that's the difference between a command function (CF) key and a command attention (CA) key.

Furthermore, it seems that there are nice capabilities for auto-complete, as well as a completely integrated build facility. From my limited time with the tool, I'm comfortable that the error reporting mechanisms are as good here as in any other WDSC editor.

On the Not-So-Positive Side

The first strike against the tool is the fact that it is a 4GL. I've explained why I don't like 4GL tools. The text interface is definitely a 3270 equivalent, and I don't see how you would easily stick, say, a UNIX character-based front-end on the program.

Next, the idea of packages and parts has just enough similarity to Java to be confusing, although when you take a closer look, you find that EGL components come in several different types--more like an iSeries/i5 source file with physical file DDS, display file DDS, and CL and RPG source all in the same source file. I'm not sure whether this is a plus or minus; as long as WDSC performs impact analysis when I rename something, I will be happy.

I'm also a bit confused as to the relationship between EGL and Web pages. As far as I can tell, you can't build a Web page from an EGL form. Instead, you design a Web page using WDSC's Page Designer and then somehow generate an interface to the EGL program. At least this was the original case with Struts, but now that WDSC has changed to use JSF, that may no longer be the case. It's not clear from the documentation, that's for sure.

Indeed the worst problem by far is the documentation. Despite the boatload of reference material, there's no clean place to get started. I'm no dope, and it took me all day just to get errors to occur. Finally, I did manage to create the following examples (use the New/Other... option from the File menu and select Examples>EGL). Unfortunately, it took me so long I don't have a lot to offer here except a couple of first glances.

A Couple of First Glances

Figure 1 shows the output of the "Text UI" for EGL. I think you'll agree that it's eerily familiar. In fact, it looks similar to something from the early days of generated iSeries code.

Figure 1: The Text UI for EGL--somebody went to a lot of trouble to get green-screen in Java. (Click images to enlarge.)

Figure 2 shows an EGL-generated JSP screen. Once again, nothing to write home about, but it was generated pretty quickly. As I mentioned earlier, though, it seems like all the JSP code was handcrafted. Not exactly my idea of a code generation tool.

Figure 2: This is your basic graphic interface for EGL.

So What Do You Get for Nothing?

One of the things I've sort of ignored throughout this rant is the price. A big plus is that this entire tool is free--well, free to you and me as iSeries/i5 developers, anyway. And even that is new; until this 5.1.2 release, EGL was part of the WebSphere Studio Enterprise Developer, a tool far out of the reach of mortal hands like ours.

So, what do you get for nothing? Certainly more than a rubber biscuit (quote courtesy of the Blues Brothers). It appears that we have the makings of an HLL that could be somewhat platform- and data source-independent, although in the code I looked at, the SQL bias was pretty clear and not isolated. I'd have to see more examples to determine how much independence this buys you.

At the same time, the code I see isn't much more "high level" than good RPG code, especially code using /free syntax. So for now the jury is out as to the value add of this particular tool. If you'd like to know more about EGL, please comment in the discussion area, and I'll add it to the list of future topics.

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 and Eclipse: Step by Step, with WDSc: Step by Step coming out in a few weeks. You can reach him at joepluta@plutabrothers.com.