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.
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.
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.
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 first published in June 2009