RPG to Java
RPG to Java?
Relating RPG and Java on the same line seems pointless. Of course, both are programming languages, but the first is a procedural language that dates back to 1959, with high dependencies on the deployment platform. The second is a modern alternative that appeared in 1995, with object orientation and freedom to deploy in any environment.
RPG and Java are two languages that are difficult to compare; therefore, transferring RPG code to Java poses a significant challenge.
For several years, there has been an increasing need in the market to modernize old RPG applications to a GUI, WEB, Cloud, or even a mobile or open-source environment.
Additionally, IBM encourages companies to convert the RPG to Java/J2EE.
The RPG to Java modernization challenge is on.
Some concepts about RPG and Java.
RPG is a language that IBM conceived for its 1401 computer (1959 – 1971). Still, its great popularity is linked to the IBM AS/400 (1988), a medium-sized platform for business applications that became extremely popular in the 1990s. Today, in its modern versions, we name IBM i. The AS/400 and RPG tandem’s success was so great that it still handles millions of daily transactions.
However, this language, which has completed an enormous 70-year cycle, has poorly aged, demonstrating the inability to respond to IT departments’ current demands. In honor of RPG, its origins are very distant from now; it was born as a language for helping the transition from tabulating machines to the first modern computers. It has been with us from that moment in our prehistory to the present day what is undoubtedly exceptional.
Due to their widespread use, the applications developed in RPG for AS/400 are now the subject of study to find modernization solutions for current platforms. There are tremendous experience, good ideas, effort, and valuable applications stored on those platforms. A heritage that we cannot lose.
But evolution between such disparate environments is not trivial. It quickly becomes evident that the modality of working and the architecture of the applications designed in both languages are entirely different, often opposite.
These differences force us to thoroughly study the original RPG system, discover all the significant points, and understand the potential language change issues and the associated risks.
Only this process of analysis and knowledge can ensure success. And this process must be carried out following precise protocols that guarantee the consistency of the new system and the quality of the new code to deploy in the target environment.
Sure, there are no magic solutions, but there are solid and well-tested ones. Technology, tools, conscientious work, and experience are required, but the treasure written in RPG and deposited inside the AS/400 can again shine on modern platforms with reduced times and costs.
People
While many converters and transpilers on the market promise to do the job of converting RPG to Java, these processes generally fail on the human side.
It is not enough to translate from RPG to Java; first, you have to understand and clean the Legacy system to modernize. They are systems 10, 20, and 30 years old with many aspects that need improvement.
The experience and knowledge of the team in charge of the migration are also decisive. Neither forgetting empathy and understanding towards the people who use and maintain the old Legacy software and who legitimately consider it “their creation”.
All those responsible for making the decision, creating the system, and its users must find benefits from the modernization process and the results.
These crucial messages can only be communicated correctly by a team with the experience and empathy trained for this purpose.
The goal is not just a translated software working precisely like the original RPG code; this is obvious. It is also vital that the people related to the Legacy system actively participate in the modernization process, either by collaborating in the preparation of the protocols that will be applied, as well as in the validation tests and certification of the converted code.
Some points of attention.
As we have already mentioned, RPG and Java are two very different realities. Managing those differences that should be points of attention is a success factor.
We can quickly point out some of these topics.
- Platform dependency
The RPG is practically embedded within the AS/400 platform. This strong dependency on the RPG code and the operating systems is the first hurdle to overcome.
The intensive use of OS included within RPG programs is perhaps the biggest problem. For example, alternatives to features such as Open Query File (OPNQRYF), Work Submitted Job (WRKSBMJOB), or Work Spool Files (WRKSPLF), which RPG programmers permanently use, must be sought.
- Access speeds
RPG queries based on PF (physical file) and LF (logical file) file systems are high-speed, so optimizing SQL queries on the target platform is also crucial. An AS/400 programmed in RPG is a speedy platform running business applications that include many disk access. The resulting system must maintain or improve these features. It is not always easy.
- Processing logic
The RPG is a language designed as unstructured, but we must translate it into Java, a modern, strongly structured language. So, for example, a list of flow instructions, which will probably include a significant number of GOTOs, will need to be converted to structured code.
- Rigid instructions
Some of the instructions in RPG code deviate from the paradigm of open systems and Java. For example, screens and programs are tightly coupled, making it difficult to evolve to a multi-tier architecture.
Or the handling of information at bit level with instructions such as BITON and BITOF.
- The encoding problem
Although the first answer to data migration is converting the AS/400 files to tables in an RDB and transforming the EBCDIC to UTF-8, in some cases, due to linking with external systems that also use EBCDIC, this solution can be problematic. There is no single formula; only a detailed system analysis can guide us.
Impact of migration
- Reduction and rationalization of costs.
The final product will require an infrastructure with lower costs, but also the software licenses show significant savings compared to the Legacy platform.
Perhaps the fundamental point is that all investment now will be directed towards the future of our IT system.
We will stop investing in technologies that we know are obsolete and, sooner or later, will have to be replaced.
- Higher productivity and better control
In addition, productivity increases visibly, and testing and development times reduce, lowering total maintenance costs.
On the other hand, many modern tools will allow the control of our DevOps operations that we currently lack.
- Technology standardization.
Modern standard-type technology presents easy integration points with own or third-party subsystems. Thus overcoming the “island” effect produced by Legacy systems, with which it is difficult to interact.
- New world of resources.
The new technology and the technicians who know it are more accessible than on Legacy platforms.
All the resources involved can be replaced and modernized easily.
In addition to faster maintenance, the skills required to maintain the system are easier to hire, guaranteeing continuity.
How to migrate from RPG to Java
Undoubtedly, Base100 provides one of the most flexible options to start down the legacy application modernization journey and the best analysis tools available.
Platform-independent, the Base100 approach emphasizes not limiting the target platform options, being able to select state-of-the-art interfaces based on HTML5 or Java frameworks such as Angular or React, to choose among any RDBMS or very different architectures.
Also, after an evaluation of the system to be transformed, a modernization plan is built where we can choose the appropriate solution for the Caravel set.
Caravel Express type, accessing practically automatic translations through a rehosting in Java or Caravel Convert, including a tool-based reengineering where human intervention is oriented to the final aspects.
Base100 does not make rigid approaches and long-term processes, offering highly flexible results in short times.
With Base100, you are assured that all the functionality of the operating system and all types of Legacy objects is converted, guaranteeing identical behavior on the target platform.
The resulting system transforms the AS/400 architecture to current open architecture standards, whether to be deployed on-premises or in the Cloud.
The modernization of legacy applications
This is the reason for Base100 to exist. It’s what we do. It is who we are.
We know that Legacy Systems must migrate to new technologies, but we are aware that decisions are made by the people who live with that system every day.
We want to help you make the best possible decision for each of the specific problems you face.
Trust the Base100 experience!
We offer you technology and tools that guarantee the process of implementing Mainframe z/OS or IBMi AS/400 modernization solutions towards more modern technologies is guaranteed to be unquestionably successful.
You can continue here:
- Introduction to Caravel technology
- Caravel Frequently Asked Questions
- How to request a Proof of Concept
Are you interested in the proposal?
Let’s move on and talk about modernization!
Freepick images
