Migrating iSeries (AS/400) Legacy Applications to Azure

The platform was first introduced as the AS/400 (Application System/400) on June 21, 1988 and later renamed to the eServer iSeries in 2000. The IBM System i is IBM's previous generation of midrange computer systems for IBM i users, and was subsequently replaced by the IBM Power Systems in April 2008.

One feature that has contributed to the longevity of the IBM System i platform is its high-level instruction set (called TIMI for "Technology Independent Machine Interface" by IBM), which allows application programs to take advantage of advances in hardware and software without recompilation.

The AS/400 has been a very robust platform in the past decades, offering the compatibility mentioned above, which has allowed customers to keep building up their legacy applications with no or minimum migration effort involved.

But times have changed.

Now, one of the biggest decisions IT managers have to make is how and where to run data center applications in order to lower costs and increase business agility.

There are multiple options, including server virtualization, internal clouds, public clouds, and external private clouds.

Skytap and Microsoft just announced a new collaboration to bring Skytap’s IBM POWER-based cloud service to Microsoft Azure.

Once running on Azure, legacy applications can be enhanced with web services, mobile capabilities, AI and IoT. Legacy workloads will seamlessly span old and new hardware and software architectures, giving the ability to extend the life of traditional systems and increase their value by modernizing with Azure services.

One important argument to move out of proprietary hardware and software platforms is that applications have been developed using legacy programming languages like RPG and COBOL, and programmers with these skillsets are retiring.

The new generation of software programmers don’t know RPG nor COBOL and are not interested in knowing them at all. Nowadays, they graduate from school knowing modern web technologies used by large software companies like Microsoft, Google, Facebook and Amazon. Such technologies include JavaScript, NodeJS, PHP, React, Angular, SQL Server, Cosmos DB and MySQL, to name a few.

AS/400 RPG and COBOL, like any other proprietary programming languages, use other software tools developed exclusively for running on their native platform, in this case, the AS/400, such as DDS (Data Description Specifications) to design screen formats as well as data files (physical and logical).

The screen format specifications allow programmers to embed business rules into the screen format itself, making it tightly coupled to the business rules. If at the same time, the RPG or COBOL code contain more business rules, that makes applications even more complicated to maintain.

All of these technical issues are contrary to the modern development practices, where the functional, independent-object approach is applied to the different layers of the development cycle: user interface (UI), web server and database. Each layer should be independent of the rest of the application.

“Low Code” development tools like SYNON(CA 2E) or LANSA have been used to build legacy applications for the iSeries platform, designing the applications in their respective IDEs but generating at the end RPG or COBOL code.

And finally, the most of the legacy systems were big monoliths, running either as a single process or a small number of processes spread across a handful of servers. They have slow release cycles and are updated relatively infrequently. At the end of every release cycle, developers package up the whole system and hand it over to the ops team, who then deploys it and monitors it.

Today, these big monolithic legacy applications are slowly being broken down into smaller, independently running components called microservices. Because microservices are decoupled from each other, they can be developed, deployed, updated and scaled individually. This enables you to change components quickly and as often as necessary to keep up with today’s rapidly changing business requirements.

Microsoft has built an ecosystem of partners who can provide a specific solution for AS/400 users, based on their current requirements and needs:

1. Lift-And-Shift. RPG, COBOL and CL applications are migrated and executed in a very similar environment as the AS/400. It takes few weeks to move applications and data to Azure. The applications can still be maintained in their respective legacy source code, or in the converted code which is C for business rules, and JAVA for User Interface.
2. Modernization. The RPG/COBOL/CL/SYNON/LANSA source code or specs of the legacy applications is transformed into either JAVA, C#, PHP or Javascript. In the case of SYNON/LANSA, the migration is done based on the application specs, not from the RPG/COBOL code generated by those tools.
3. Migration of DB2 databases (including any physical and logical files) to Cosmos DB, Azure SQL, SQL Server, MySQL, MariaDB or any other relational database.
4. Implementation of microservices, containers and orchestrators.

Migrating iSeries (AS/400) Applications to Azure

At the end, the customer can choose which operating system (Windows, Linux), Web Server (NodeJS, IIS, Apache) and database (SQL Server, Azure SQL Database, MySQL, MariaDB) they want to use.

The retirement of RPG/COBOL programmers won’t be an issue anymore. Both development teams, RPG/COBOL and JAVA/C#/C/PHP/Javascript programmers, can work together to maintain the applications and do the knowledge transfer easily.

Advantages:

• Reduce hardware and software infrastructure costs
• Modernize legacy source code, user interface and databases
• Improve the maintenance and deployment of the converted applications
• Smooth transition from the AS/400 to Azure

For more information, please contact the AS/400 Division at the Azure Global CAT Engineering team.