EGL

EGL - Enterprise Generation Language - is IBM’s answer to a question most language designers never ask: what if the compiler’s output were not a binary, but source code in whatever language your operations department already supports? EGL is not compiled. It is generated. The same EGL program can be turned into COBOL for a CICS region on z/OS, into Java for a WebSphere application server, or into JavaScript for a browser, and the generator - not the programmer - deals with the middleware, the transaction semantics, the SQL binding and the wire protocols.

That design makes EGL an unusual object. It is a modern statically typed language with nullable types, services and an annotation system, aimed squarely at people whose job title is “business application developer” and whose production environment is a mainframe. It descends in a direct line from Cross System Product, an IBM 4GL that dates to 1981, and it is still shipping: the tool that generates it, IBM Rational Business Developer, released a refresh pack in March 2025.

History and Origins

EGL is the third name on a product line that has been in continuous existence since the early 1980s.

IBM Cross System Product arrived in 1981 as an application generator for interactive mainframe systems, split into CSP/AD (the development environment) and CSP/AE (the runtime). It let developers define, test, generate and execute applications interactively at a time when the alternative was a COBOL compile-link-test cycle that could take hours to turn around. CSP’s last release, version 4.1, went out of support at the end of 2001.

VisualGen replaced it in 1994, adding client/server development, GUI construction and access to non-IBM data stores - the concessions the mainframe world was making to the distributed one. It was renamed VisualAge Generator in 1996; IBM withdrew VisualAge part numbers from marketing effective September 2008, and support for VisualAge Generator V4.5 ended on 30 September 2009.

EGL itself first shipped in 2002, as a component of WebSphere Studio Enterprise Developer V5.0, which became generally available around September/October of that year. The framing in IBM’s material of the period is precise about what the language was for: it would let Java and non-Java programmers alike build full-function COBOL and J2EE Java applications from a single, easy-to-learn source language. EGL support reached the iSeries tooling in 2004 with WebSphere Development Studio Client Advanced Edition V5.1.2.

The language got its own product in 2006, when IBM shipped Rational Business Developer Extension V7.0 - the first IDE built around EGL rather than one where EGL was a feature among many. Version 7.0 added the Boolean primitive, the ExternalType part for reaching into non-EGL code, and a substantially expanded service story: EGL could generate the parts needed to call a service straight from a WSDL file, and EGL-authored services could be generated for Java or CICS deployment. Because RBDe is where most people first encountered the language, EGL is often dated to 2005-2006 rather than 2002.

The Eclipse detour

In 2011 IBM did something it had not done with CSP or VisualAge Generator: it gave the language away. The core of EGL was donated to the Eclipse Foundation as EGL Development Tools (EDT) under the Eclipse Public License 1.0, with the stated goal of providing “an open, non-proprietary language to use and extend for multi-platform development” - and, candidly, of increasing adoption of a language IBM believed people liked once they tried it.

EDT split the technology in two: EGL Core, the language definition and its basic syntax rules, and the Eclipse IDE tooling around it - editors, views, wizards, builders, compilers and generators. IBM continued to sell Rational Business Developer alongside it, differentiated by the enterprise pieces EDT did not get: COBOL generation, additional deployment targets, and integration with third-party databases.

Four releases followed - 0.7.0 on 2 December 2011, 0.8.0 on 13 April 2012, 0.8.1 on 1 August 2012, 0.8.2 on 18 January 2013 - and then nothing. EDT never graduated from Eclipse’s incubation phase and lists no active member companies. The open-source experiment lasted about fourteen months.

Design Philosophy

Generation, not compilation

The defining decision is in the name. An EGL build produces readable COBOL, Java or JavaScript, and that output is a deployable, debuggable, operationally normal artifact on its target platform. A mainframe shop gets COBOL that its existing job scheduling, abend handling and source management understand. A Java shop gets Java that runs on its application server. A browser gets JavaScript.

The trade is deliberate. You give up direct control over the generated code - you do not hand-edit it, and regeneration overwrites it - and in exchange the same business logic outlives the platform it was written for. An EGL program written against CICS in 2004 could be regenerated as a Java service later without rewriting the logic. For organizations whose applications are older than their programmers, that proposition is the entire pitch.

Abstraction as the product

IBM’s framing throughout EGL’s life is consistent: the language’s job is to hide interfaces the business developer should not have to learn. The EDT project description puts it plainly - EGL “simplifies development by hiding the complexities of Ajax, JavaScript, REST, and SOAP” - and Rational Business Developer’s positioning is that programmers can use Java, Java EE, browsers, cloud deployment, databases, IBM i and IBM Z “without having to learn all the underlying technologies.”

This is a genuinely different goal from most language design. EGL is not trying to be expressive, or fast, or minimal. It is trying to reduce the number of technologies a person must hold in their head to ship a working transactional business application - and it accepts a large, opinionated, IBM-shaped runtime as the price.

Stereotypes

EGL’s most distinctive syntactic feature is the stereotype, a concept borrowed from UML. A part - EGL’s word for a top-level program element - is declared with a type, and the stereotype attached to it tells the generator what kind of thing it is and what rules apply. A record with the SQLRecord stereotype is not just a struct; it is a struct the generator knows how to read and write against a database table. A handler with RUIHandler is a browser component. A BasicProgram is a main-line program with an entry point.

Behaviour that other languages express through inheritance, framework base classes or naming conventions, EGL expresses declaratively, and the generator supplies the implementation.

Key Features

Parts. EGL code is organized into parts: program, library, record, service, handler, interface, dataTable, form, externalType, delegate. Parts live in files and are grouped into packages, Java-style.

Programs. The classic entry point:

package com.example;

program HelloWorld type BasicProgram
    function main()
        SysLib.writeStdout("Hello, World!");
    end
end

Records and SQL. A record with the SQLRecord stereotype binds a data structure to a table, and I/O statements act on it directly:

record Customer type SQLRecord { tableNames = [["CUSTOMER"]] }
    custId INT { column = "CUST_ID" };
    name   STRING?;
    balance MONEY;
end

Database access uses statements built into the language - get, add, replace, delete, with forUpdate and cursor forms - rather than a library API. Static SQL is generated from the record definition; explicit SQL can be supplied where the generated statement is not what you want.

Services. A service part exposes functions to the outside world, and the generator produces the SOAP or REST plumbing:

service CustomerService
    function getCustomer(custId INT in) returns (Customer)
        myCustomer Customer;
        myCustomer.custId = custId;
        get myCustomer;
        return (myCustomer);
    end
end

Rich UI. An RUIHandler is a browser component that generates into JavaScript, declaring its widget tree in the initialUI annotation:

handler HelloHandler type RUIHandler
    { initialUI = [ greeting ], onConstructionFunction = start }

    greeting TextLabel { text = "Hello, World!" };

    function start()
        greeting.text = "Hello from EGL Rich UI";
    end
end

External types. The ExternalType part, added in version 7.0, describes a Java class or JavaScript object to the EGL compiler so it can be called from EGL with type checking - the escape hatch that keeps the abstraction from becoming a cage.

Nullable types. The ? suffix on a type declaration marks it nullable, matching SQL’s three-valued reality rather than pretending it does not exist - a practical necessity in a language whose primary data source is a relational database.

Evolution

The pattern is worth noticing: every major EGL milestone is a product announcement, not a language release. EGL has no independent standards body, no competing implementations of consequence, no package ecosystem in the npm or Maven Central sense. The language’s version history is IBM’s release calendar.

Current Relevance

EGL is dormant, not dead, and the distinction matters.

Dormant, because the open-source implementation stopped in January 2013 after four incubating releases, the Eclipse wiki that documented it is frozen read-only, and the language has little visible presence in the places where language communities live now - scant GitHub activity, no conference track of its own, and next to no public hiring market. If you have not worked in an IBM enterprise modernization shop, there is a reasonable chance you have never met anyone who has written it.

Not dead, because the commercial product remains in support and under active maintenance. Rational Business Developer 9.6 shipped in October 2019 with support for Bootstrap and Ionic; 9.7 went generally available on 17 June 2022; refresh pack 9.7.2.0 was released on 28 March 2025. IBM maintains current documentation, and the customers who run EGL applications are running them in production, on mainframes, today.

That is the characteristic shape of an enterprise 4GL’s later life. Adoption is nearly zero and attrition is nearly zero at the same time, because the code that exists is load-bearing and the cost of replacing it exceeds the cost of continuing to pay for the tool.

Why It Matters

EGL’s interest is architectural rather than linguistic. Its syntax borrows visibly from COBOL and Java and breaks no new ground. What it demonstrates is a strategy for the problem that dominates enterprise computing and barely registers in language design: what do you do with working software whose platform has outlived its era?

The industry’s usual answers are to rewrite (expensive, risky, frequently abandoned), to wrap (accumulates layers, defers the problem) or to freeze (works until it does not). EGL proposes a fourth: raise the source of truth above the platform, and make the platform a generator target. Get the business logic into a language that can be emitted as COBOL today and as Java or JavaScript tomorrow, and the platform migration becomes a build-configuration change rather than a rewrite.

Whether that worked is genuinely arguable. It required trusting a single vendor’s generator with your source of truth - and EGL’s own history, from CSP through VisualGen through VisualAge Generator to EGL, is four decades of migrating between IBM’s successive answers to the same question. The abstraction that was supposed to outlive platform churn ended up participating in it.

But the idea keeps coming back. Every low-code platform that generates deployable applications, every model-driven engineering toolchain, every transpiler that treats a target language as a compilation artifact rather than a language, is working the same seam EGL worked. EGL is the version of that idea that has been generating production mainframe transaction code for more than two decades, which makes it worth studying more carefully than its obscurity suggests.