EGL: The Future of Programming for the System i?
September 17, 2007 Timothy Prickett Morgan
The IT managers cut the checks in the data center world, but the programmers and system analysts do the work to make machinery turn into the software that controls how the business operates. The programmers are the ones who have the brains to actually make the complex code that allows businesses to be simplified and automated, and it is an unwise vendor that antagonizes the programmers on its systems and a wise one that tries to court as many programmers as possible to a platform. The IT managers may write the checks, but programmers have the most influence over what technologies checks will be written for.
And so, platform vendors–by which I mean those who supply a complete operating system, database, application runtime, and software development environment–always have a tricky time making changes. Any major change with an existing toolset will be met with about the same amount of love that Americans showed when they were encouraged decades ago to shift to the Metric System of measurement, the standard in most of Europe and in lots of other parts of the world. The irony is that some of these very same programmers, craving features in other programming languages, are also constantly pushing their platform vendors to alter them radically to support new technologies.
There is a constant tug of war going on, and it is rare when programmers or platform providers are all happy at the same time. But all of this pushing and pulling is how change happens.
Such was the case when computer-aided software engineering (CASE) tools based on Smalltalk were introduced as part of the AD/Cycle cross-platform application development environment by IBM in 1990 for its S/390, AS/400, and newbie PS/2 and RS/6000 platforms. While the AD/Cycle tools promised increased programmer productivity, the object-oriented programming techniques were alien to those experienced with high-level procedural languages like RPG, COBOL, and Fortran. Moreover, programmers who were long-since used to tuning code to wring performance from their very expensive systems were being asked tell their managers that using such a tool could require a lot more iron because generated code was not anywhere near as efficient as the code they could create.
IBM dropped AD/Cycle and its Cross Systems Product program generator like a hot potato when it caught the Java bug in 1997, but it held onto the Smalltalk generator that it got through the acquisition of Object Technology International, and this laid the foundation for the VisualAge family of development tools, which could spit out applications written in Java, RPG, COBOL, Smalltalk, Fortran, and numerous other languages. When IBM became a licensee of Java and embraced Java as its cross-platform development environment, you could basically global replace Smalltalk with Java in the press releases. The technology had changed, but the strategy had not.
And here we are, a decade after the Internet has been commercialized, in a generation that some people call Web 2.0 with applications that have what is often called a services-oriented architecture (SOA), and the same push and pull is going on. And, with some modifications, IBM has the same strategy for attacking the issue. In this case, it is called Enterprise Generation Language, or EGL, software that has its roots in the AD/Cycle and VisualAge tools.
This notice in the System i announcement letters from July 31, when the Power6-based i5 570 and the i5/OS V6R1 preview were discussed, caught my interest:
“With the shift of responsibility for the System i compilers and application development products to the Rational line of business, IBM will work to enhance the integration and synergy of the System i development products, such as WebSphere Development Studio Client (WDSC), with other Rational offerings. The Rational Suite of products provides key function to enhance a developer’s environment in areas such as the rapid development of modern application architectures for System i (Rational Business Developer, formerly Enterprise Generation Language), modeling of application solutions, quality management, and change and configuration management. The tighter integration of these products to the System i development community will further enhance the comprehensive function included in WDSC today.”
First of all, no one is going to call it RBDe–the little “e” is for “extension.” Everyone is going to call it EGL. Even IBMers do. So I am not going to change this name until I see people actually shift to RBD or RDBe. I would also point out the missed opportunity to have called this language the Rational Program Generator. I am kidding, for obvious reasons. Although if EGL could be coaxed to generate ILE RPG code (also known as RPG IV code), then EGL could be called RPG V, a superset of RPG IV. It has a nice ring to it.
Before I get into a discussion I had with Bob Cancilla, System i software evangelist, and George Farr, worldwide product manager for application development tools and compilers for the System i, you should probably take a gander at what EGL is and how it fits in with the products in IBM’s Rational software development tools division. So check out this link.
Back in March, as it turns out, the WebSphere Application Integration Middleware group within Software Group was transferred to the Rational tools division. This WebSphere AIM group was responsible for the System i and System z compilers. IBM did not make a big deal about this, and the move is not unexpected, since IBM did spend $2.1 billion back in December 2002 to buy development tool maker Rational Software.
For a few years, there have been rumors that IBM would somehow extend RPG so it could automatically and transparently generate Web screens for RPG applications on the i5/OS and OS/400 platform. While there are plenty of tools available to help customers do this–many of the providers of such tools make this very newsletter you are reading possible, for which we thank them–given the integrated nature of the AS/400, iSeries, and System i, many people were nonetheless still hoping to have it all come together in one offering, ready to go out of the box. This was sometimes referred to as RPG Multi UI, the UI being short for user interface, of course.
Coincidentally in March, while IBM was exploring its options and the System i tools from IBM were being put under the control of Rational, I noodled the idea of using EGL to generate RPG code and the associated screens for applications. (See What’s IBM Cooking Up for RPG and the Web?) Cancilla says EGL should not be considered a fourth-generation programming language (4GL) so much as a high level language that makes it possible for programmers who are used to creating code with procedural languages to end up with Java or COBOL code, created by the EGL generators. It seemed reasonable, given the fact that the EGL tools can generate COBOL for i5/OS V5R4 or OS/400 V5R3 with its integrated DB2/400 database as well as for z/OS 1.6 or higher running on IMS databases or CICS/VSAM files, that EGL could be tweaked to do for RPG what it does for COBOL. EGL also generates Java code and screens, which can run on the same releases of z/OS and i5/OS-OS/400 as well as on AIX 5.2 and higher, Windows 2000 Server and Windows Server 2003, the past few iterations of Linux from Red Hat and Novell, Hewlett-Packard‘s HP-UX 11i v2, and Sun Microsystems‘s Solaris 9 and 10.
As it turns out, neither the extended ILE RPG with some kind of native interface generation capability and EGL is not going to be extended to support RPG.
“We’re not going to build RPG Multi-UI,” explains Cancilla. “EGL is our strategic path. And while we generate Java and we generate COBOL with EGL, we are not going to generate RPG.” Farr immediately chimes in to soften how that sounds. “We are putting the right hooks between RPG and EGL so that we do not have to reinvent the wheel,” he explains. Cancilla says that EGL is the only language that IBM has in its toolbox that has native support for services built right in to the language. “With EGL, we can generate both Web services and local services, and quite frankly, the customer base is telling us that we need to become more platform neutral, and we are trying to position Rational BDe and EGL as the development environment for the future. And if you have a skill in any programming language, it takes about a week to learn the language and about a month to become proficient.”
Those are powerful words, especially to an IT manager looking to simplify how applications get created on disparate platforms. And as in the past, IBM doesn’t want programmers mucking around in the source code that the EGL tool generates, but to stay at the higher level of EGL. “We absolutely do not want programmers to touch the source,” says Cancilla.
Now, don’t misunderstand Cancilla. None of this means that IBM is not going to continue to invest in further development of RPG tools. Quite the contrary. “We are absolutely going to continue to invest in RPG,” says Cancilla, just to put it on the record. Farr echoes this, strongly, just to avoid confusion. “IBM is committed to investing in RPG, but we are also committed to bridging the System i to the future. EGL is the next business language for the System i, but RPG will continue to exist and we will continue to invest in it,” says Farr, adding that there are plenty of requirements for enhancements to RPG that IBM is working on right now.
So, for instance, as new hardware, like the Power6 and its decimal math units and integrated vector math units come to market, RPG will have hooks into this hardware so it can take advantage of this hardware. IBM also promised in its i5/OS V6R1 preview that it would provide “an integrated Web services environment with i5/OS for Integrated Language Environment (ILE) programs,” including utilities that will generate high-level APIs for ILE programs to invoke Web services and a Web services runtime environment for this tool; the idea is to take existing RPG and COBOL programs and expose them as Web services. With the next release of i5/OS, IBM is also promising extensions to the RPG compiler for multithreading and local file support, too.
And also just for the record, IBM is not asking customers with RPG applications start porting their applications to EGL–any more than IBM ever suggested a decade ago that companies should drop RPG and move to Java. “We are not advocating that System i customers convert their RPG applications to EGL,” says Cancilla. “But we encourage them to use EGL for Web services and SOA development. We know for a fact that there are very few customers who have the budget to move to a new language quickly.”
It took a decade for ILE RPG and Java to make a dent in OS/400 and i5/OS shops, and there is no reason to believe that the uptake for EGL will be any faster.
One last thing: The fact that EGL can generate COBOL, which is particularly important for batch jobs, and can talk in a native way to DB2/400 through COBOL, means that perhaps RPG is not necessary in a world where coders work through EGL and don’t touch the source code anyway. Yes, that sounds very weird. And yes, I wish that IBM would just spend the money and generate RPG on equal footing with Java. But, then again, IBM is not generating Microsoft‘s C#, either. At least not yet.