Problem solve Get help with specific problems with your technologies, process and projects.

Migrating from RPG to EGL on IBM i

The IBM Rational Migration Extension for IBM i (RMEi) migrates existing RPG programs to EGL. Learn when migrating from RPG to EGL may have advantages to your business, and how EGL integrates procedural and object-oriented langauges into the same space.

The IBM Rational Migration Extension for IBM i (RMEi) migrates existing RPG programs to EGL on all IBM platforms....

With SOA, EGL closes the gap between procedural and object-oriented languages, allowing developers to focus on making business-ready modern programs without having to learn Java.

Some ask, "How future-proof is the RPG programming language? Is it worth doing further development on it?" There has been a lot of discussion and speculation revolving around these questions over the past few years. Even though further development is still being made to RPG, Java and other object-oriented programming languages are on the rise. Despite this, RPG still has as many fans as it always has because in contrast to Java or .NET, it is geared toward programming business applications.

Nonetheless, the market has been moving in another direction, and it looked like numerous stable, tried and tested RPG applications were going to be quickly replaced by new developments. But appearances can be deceiving: the result of such migration projects in the past was often disillusioning, and many ambitious projects were prematurely canned. There's a simple reason: a paradigm gap between the procedural and object-oriented worlds makes migration a delicate matter for both applications and programmers alike. Despite the enthusiasm the open source community radiates, it is clear that native Java is not the business language of the future. At the same time, it's undisputable that RPG is anything but elegant when it comes to developing something like a Web 2.0 application.

Enter, IBM Rational, with the EGL business language (enterprise generation language). EGL is a latest-generation programming language that takes both client and server-side needs into consideration when developing business apps. Modern front-ends based on JSF and Ajax technology can be created, as well as classic batch programs with text-user interfaces like 5250. And, Java programs can be generated directly from within EGL and native i programs.

EGL is not object-oriented — it's a procedural programming language in which modern SOA aspects are implicitly integrated. Thus, it seems that a bridge that was previously missing has now been built between the traditional and object-oriented worlds.

But how can tried and tested RPG applications that have worked for years, and that may be the backbone of a business be safely and efficiently migrated to EGL? This where the IBM Rational Migration Extension for i (RMEi) fits in as a potential solution. With RMEi, existing RPG programs can be migrated to EGL. The advantage to switching to EGL is that it closes the gap between the procedural and object-oriented worlds. This had been too much of a strain on most application developers in the past, and it usually led to results that were difficult to service. Modernizing the user interface might have been a good start, but just screen scraping increases the complexity without providing any improvement of the functionality.

EGL: Procedural and object-oriented

EGL is easy for programmers to learn and is highly productive, making it much easier on RPG developers who might otherwise attempt direct migration from RPG to Java. Additionally, RPG developers don't need additional know-how in the area of complex Java and OO technologies.

EGL is based on Eclipse, making it a modern development interface. Because it is at least 25% more efficient than native Java developments, it boosts developer productivity. EGL has adopted many tried and tested concepts from RPG and combines them with the most modern standards for user interfaces, services, architecture and platform-independence. Everything is integrated in Eclipse and can be mastered by RPG programmers within two to four weeks. RPG programmers can then finally do things that only their Java and .NET colleagues were able to in the past, and do it on the IBM i.

Either native code or Java can be generated from EGL. Native code is optimal for high performance jobs in IBM i such as batch applications or interactive applications with a very high number of users. Java on the other hand is completely platform-independent. The decision for Java or COBOL can be made ad hoc at any given time – there's no need to make any prior commitment to one specific technology. And, migration to EGL can extend the lifecycle of an application by 10 years.

Why EGL?

EGL combines the strengths of both worlds: modern, platform-independent Java development with RPG's simplicity and high degree of productivity.

EGL is the strategic business language from IBM.

  • Reduces risk of migration with IBM Migration Roadmaps (VAGen, Natural, Cobol, RPG).
  • Includes SOA as the integral part of the language and development environment.
  • Allows for full concentration on business demands, saving the hassle of having to deal with the technology.
  • Generates COBOL for maximal performance.
  • Generates Java for interactive programs and front-end.
  • Has a short learning curve: just two weeks of training; productive work is possible after four weeks.
  • Features an open language and toolset with a high degree of interoperability and flexibility so other languages can be integrated and deployed independent of platform.
  • Has a simple and procedural language with assistants and built-in functions.

Has been submitted to the OMG for standardization.

Because RMEi supports step-by-step modernization, extensive applications can be split up into smaller bits that are more easily manageable. EGL offers the added value of also being able to consolidate other programming languages like Natural, VAGen, Informix 4GL and COBOL.

Click on image for larger version
The EGL development environment

Click on image for larger version
Typical EGL language constructs

Migrating to EGL

It makes sense to migrate to EGL when the debate occurs at a company regarding replacing proprietary developments with standard software. It would also make sense to consider migration when RPG can no longer meet new demands, and Java or .NET is needed. Another consideration is user convenience – EGL may be a good choice when many users need to continually switch back and forth between a GUI and green screen. Lastly, a sign it might be good to switch is when program customizations and extensions can no longer be executed in real-time and development becomes a mission critical bottleneck.

From RPG to EGL with the IBM Solution Roadmap for IBM i

Developers represent an enormous amount of value: they hold the knowledge about the company and its actual procedures. Therefore, AS/400 users need a solution for migration that takes both the application and know-how and background of the developers into consideration. Apart from the existing application itself, this knowledge also has to remain usable in the modernized application. RMEi provides "migration in different-sized steps," which is optimally supported by different, combinable scenarios:

  • RPG and EGL can be integrated via database and program calls, making it easy to establish a connection between old and new worlds.
  • Web API technology allows integration at the UI level so that end-users experience an integrated workflow.
  • Direct code migration from RPG to EGL means that relevant areas of applications will lead you directly to the "new world" without rewriting everything.

Click on image for larger version
Calling and migrating RPG batches

Click on image for larger version
Calling, wrapping or migrating RPG services

Click on image for larger version
Integration at UI level via Web API technology or step-by-step migration

With EGL and RMEi, IBM has created a platform that travels the trails of migration sensibly and economically. Because RMEi supports step-by-step modernization, extensive applications can be split up into smaller bits that are more easily manageable. The extent of knowledge about individual languages is reduced, and all IBM platforms are supported.

ABOUT THE AUTHOR: Heidi Schmidt is sales manager at PKS Software GmbH in Ravensburg Germany. 

This was last published in June 2009

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.